Added NoError type

[NachoSoto]

Fixes #130

[gfontenot]

Is it weird to hide this away at the bottom of Result.swift?

This seems to be a general pattern we're using so it's probably not worth holding up this PR for. I do wonder if we shouldn't do a pass at better file organization though.

[gfontenot]

Anyway, I dig the change. Good stuff.

[JaviSoto]

Is it worth exposing an extension on Result where Error == NoError with a var that returns a non-optional T value?

Other than that 👍 this is great!

[NachoSoto]

Is it weird to hide this away at the bottom of Result.swift?

Good point, I didn't consider that. It's definitely more important than that! I'd consider how it looks when looking at the generated "header" Swift module though.

[NachoSoto]

Is it worth exposing an extension on Result where Error == NoError with a var that returns a non-optional T value?

Ooooh good idea!

[robrix]

Lovely ❤️

[NachoSoto]

What do people think of the 2 questions?

• Location: @gfontenot where would you recommend placing it instead?
• non-optional value in an extension with where Error == NoError?

[gfontenot]

I don't know that I have a better recommendation right now (other than maybe just a NoError.swift file). I'm OK with not changing anything here and instead doing a larger audit on the organization later.

[gfontenot]

Oh, and I love the idea of a non-optional value property. Should it be named something else to avoid ambiguity?

[NachoSoto]

It can probably share the same name (because of lvalue type inference), but it would mean that some users would have to explicitly specify the type, so maybe we should provide a different name?

I filed this radar (dupes appreciated! maybe I should submit to swift-evaluation?) precisely for this reason. Ideally the optional type would not exist for NoError.

[mdiep]

I'm going to go ahead and merge this as-is. I don't think the location is terribly important (and can be changed later) and Swift doesn't make a non-optional variant very easy.

[NachoSoto]

😍