Re: [swift-evolution] [Proposal] Type Narrowing

[Dennis Lysenko via swift-evolution]

Jean-Daniel, I agree with the first part of your assessment fully, which in
my opinion is actually why I think the Kotlin style combined with the Swift
style would pull in the best of both worlds and create a complete solution.
I do share some of your reservation in the second part of your assessment,
which is why I'm a little hesitant on the proposal, but as I've described
before I think it would help expressiveness.

On Sun, Nov 13, 2016 at 11:16 AM Jean-Daniel <d...@xenonium.com> wrote:

> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> That's a good point in Jay's example and from what I can tell a good way
> to address it, Haravikk.
>
> I've done some work in a language that only provides type narrowing for
> immutable types (that'd be Kotlin as I've mentioned before) and whenever
> I've used it it feels like the only thing it's really been missing is the
> "if let" construct allowing you to bind and unwrap mutable values, which
> leads me to think that synergistically, in Swift, this would be fantastic.
> The main benefit probably is that it would allow code to read much better.
>
>
> IMHO, the Kotlin solution is flaw. The fact that type narrowing does not
> works for var and that there is no simple way to unwrap optional just force
> the developer either to introduce local variable, or to use the force
> unwrap operator.
> Moreover, introducing a unwrap syntax (if let) like in swift would just
> result in having 2 different and inconsistent way to do the same thing.
>
> I think the "type stack" phrasing in the proposal is throwing some people
> for a loop making them think it'll have way more mental overhead than it
> actually does in practice...really, in practice, I've used this either (a)
> for checking nullity or (b) for checking for a specific subclass. There's
> little to no mental overhead in either of those cases, as your "type stack"
> is simply 2-long (this was an Int? outside of this conditional block, and
> it's an Int inside. This was a UIViewController outside of this conditional
> block, and it's a UINavigationController inside.)
>
> While it may not be a panacea that allows new applications that no one
> could have thought of, I have no doubt that it would greatly improve the
> experience of coding in the language by, as you said, allowing more
> flexibility in expressiveness. Regardless of one's opinion on the efficacy
> of this feature as a whole, there *are* frequent situations where this
> feature leads to substantially better-reading code. The "unwrap" keyword
> proposed in another thread, critically, solves only *half* of the
>  problems that this proposal solves (as far as I could tell from reading a
> few emails in the chain, it left the subclass inference completely
> untouched). Ability to say "if (controller is SongSelectionViewController)
> { controller.search(for: "mozart") }" is mentally freeing and helps me stay
> in coder zen.
>
> IMO, it would effectively be the cream cheese icing on the top of the
> carrot cake of Swift's unwrapping and type inference features. A good
> tasteful cream cheese icing always improves a carrot cake.
>
> The question then becomes, is it really worth the implementation time?
> This is something that, presumably, someone from the Swift team would need
> to be involved in answering.
>
> On Fri, Nov 11, 2016 at 10:52 AM Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Nov 2016, at 21:42, Jay Abbott <j...@abbott.me.uk> wrote:
>
> Consider this code:
>
> struct Pet {
> let name: String
> weak var owner: Person?
>
> init(name: String, owner: Person?) {
> self.name = name
> self.owner = owner
> owner?.pet = self
> }
>
> mutating func transferOwnership(to newOwner: Person) {
> let previousOwner = owner
> owner = newOwner
> newOwner.pet = self
> if(previousOwner != nil) {
> previousOwner!.pet = nil
> }
> }
>
> func feed() {
> }
> }
> class Person {
> let name: String
> var pet: Pet?
>
> init(name: String) {
> self.name = name
> }
>
> func givePetAway(to someone: Person) {
> if pet != nil {
> pet!.transferOwnership(to: someone)
> //pet!.feed()
> }
> }
> }
> let bert = Person(name: "Bert")let ernie = Person(name: "Ernie")var elmo = 
> Pet(name: "Elmo", owner: nil)
>
> elmo.transferOwnership(to: bert)print("Bert's pet is \(bert.pet) - Ernie's 
> pet is \(ernie.pet)&quo

Re: [swift-evolution] Swift Extensions on Overlay Structs

[Dennis Lysenko via swift-evolution]

Hmm... would it be possible to define a protocol like "UnifiedURLType",
define each of the properties you need to work with inside your extension
functions as protocol properties inside the protocol UnifiedURLType {}
declaration, create an extension UnifiedURLType {} and include
doSomething() inside the extension, and then create extensions on both URL
and NSURL causing them to conform to UnifiedURLType? (extension URL:
UnifiedURLType {}; extension NSURL: UnifiedURLType {})

You could try it, but I wouldn't hold my breath, especially if you're
planning on using absoluteURL within your extension as something as basic
as the type of that variable is already different between the two types.

Dennis

On Fri, Nov 11, 2016 at 3:08 AM Fabian Ehrentraud via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi list,
>
> Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
> Unfortunately now extensions on URL are not getting bridged back to ObjC:
>
>
> extension URL {
> func doSomething() -> URL {
> return self.absoluteURL
> }
> }
>
> + (NSURL *)swiftStructExtensionCaller {
> NSURL *url = [NSURL URLWithString:@"
> https://apple.github.io/swift-evolution/;];
> return [url doSomething];
> }
>
> The compiler does not see the method `doSomething`. Is this on purpose, or
> something that has yet to be improved?
>
> I'm aware that I could write the extension on NSURL, but that would mean a
> lot of casting on the Swift side.
>
>
>   -- Fabian
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Type Narrowing

[Dennis Lysenko via swift-evolution]

That's a good point in Jay's example and from what I can tell a good way to
address it, Haravikk.

I've done some work in a language that only provides type narrowing for
immutable types (that'd be Kotlin as I've mentioned before) and whenever
I've used it it feels like the only thing it's really been missing is the
"if let" construct allowing you to bind and unwrap mutable values, which
leads me to think that synergistically, in Swift, this would be fantastic.
The main benefit probably is that it would allow code to read much better.

I think the "type stack" phrasing in the proposal is throwing some people
for a loop making them think it'll have way more mental overhead than it
actually does in practice...really, in practice, I've used this either (a)
for checking nullity or (b) for checking for a specific subclass. There's
little to no mental overhead in either of those cases, as your "type stack"
is simply 2-long (this was an Int? outside of this conditional block, and
it's an Int inside. This was a UIViewController outside of this conditional
block, and it's a UINavigationController inside.)

While it may not be a panacea that allows new applications that no one
could have thought of, I have no doubt that it would greatly improve the
experience of coding in the language by, as you said, allowing more
flexibility in expressiveness. Regardless of one's opinion on the efficacy
of this feature as a whole, there *are* frequent situations where this
feature leads to substantially better-reading code. The "unwrap" keyword
proposed in another thread, critically, solves only *half* of the  problems
that this proposal solves (as far as I could tell from reading a few emails
in the chain, it left the subclass inference completely untouched). Ability
to say "if (controller is SongSelectionViewController) {
controller.search(for: "mozart") }" is mentally freeing and helps me stay
in coder zen.

IMO, it would effectively be the cream cheese icing on the top of the
carrot cake of Swift's unwrapping and type inference features. A good
tasteful cream cheese icing always improves a carrot cake.

The question then becomes, is it really worth the implementation time? This
is something that, presumably, someone from the Swift team would need to be
involved in answering.

On Fri, Nov 11, 2016 at 10:52 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 10 Nov 2016, at 21:42, Jay Abbott  wrote:
>
> Consider this code:
>
> struct Pet {
> let name: String
> weak var owner: Person?
>
> init(name: String, owner: Person?) {
> self.name = name
> self.owner = owner
> owner?.pet = self
> }
>
> mutating func transferOwnership(to newOwner: Person) {
> let previousOwner = owner
> owner = newOwner
> newOwner.pet = self
> if(previousOwner != nil) {
> previousOwner!.pet = nil
> }
> }
>
> func feed() {
> }
> }
> class Person {
> let name: String
> var pet: Pet?
>
> init(name: String) {
> self.name = name
> }
>
> func givePetAway(to someone: Person) {
> if pet != nil {
> pet!.transferOwnership(to: someone)
> //pet!.feed()
> }
> }
> }
> let bert = Person(name: "Bert")let ernie = Person(name: "Ernie")var elmo = 
> Pet(name: "Elmo", owner: nil)
>
> elmo.transferOwnership(to: bert)print("Bert's pet is \(bert.pet) - Ernie's 
> pet is \(ernie.pet)")
>
> bert.givePetAway(to: ernie)print("Bert's pet is \(bert.pet) - Ernie's pet is 
> \(ernie.pet)")
>
> This works as expected, but if you uncomment pet!.feed() in
> givePetAway(to:) it will crash, because the mutating function modifies
> the two-way relationship between pet and owner.
>
> In the code I use if pet != nil to demonstrate, in your proposal for
> unwrap, if I used it to unwrap pet (a value-type, but accessed through
> self so it can be modified after unwrapping because it’s not nil at the
> moment) the compiler would assume I could use it and pet.feed() would
> crash, just as pet!.feed() does now. In your proposal for type narrowing,
> it would be the same problem. This is like your foo.value example from
> the proposal.
>
> I don’t think you can get around the fact that the compiler can’t
> guarantee a type-narrowed or even unwrapped mutable value, which is why if
> let works as it does with an immutable snapshot.
>
> However, type narrowing for immutable values would still be good.
>
> This isn't a problem of mutability, it's a problem due to the use of a
> reference type (Person); this is what the classes and concurrency section
> is supposed to be describing, but perhaps I haven't made it clear enough.
> So in the example you've given self.pet can't be unwrapped because self is
> a reference type, thus you need to either use force unwrapping either with
> the unwrap! keyword or direct force unwrapping like you've used (since
> behind the scenes it's the same 

Re: [swift-evolution] [Proposal] Type Narrowing

[Dennis Lysenko via swift-evolution]

So a lot of concerns here especially ilya's are ones that wouldn't be
brought up if people looked at existing successful implementations like
Kotlin where they are clearly solved. (fyi, answer is only narrowing with
immutable values.)

Personally I think type narrowing with explicit opt-in has no value. All or
nothing, the whole meat of the proposal is in it being implicit.

I see too many people predisposed to considering this as if it's "compiler
magic" to the point where I don't feel the cost of arguing is worth what it
would bring to the language. Sure, it's a nice piece of syntax sugar but
it's not going to revolutionise it, and if it makes compilation times even
slower I'm probably against it - xcode in general has been driving me up a
wall lately with a matter of minutes for compiling and signing our (not
huge) project, so any compiler speed improvements take on increased
precedence for me.

Just my 2c.

Dennis

On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> So I'm trying to re-write the proposal with the use of a keyword for
> unwrapping in mind, to keep it simpler for myself I've done this as two
> separate proposals for the time being, one for simpler unwrapping of
> optionals, and one for type-narrowing of polymorphic types:
>
>
> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-optional-unwrapping.md
>
> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-type-narrowing.md
>
> In addition to feedback on each proposal, I'm interested to know whether
> people think it is better to keep these separate? They're still very
> similar features, but the differences make it pretty awkward to keep them
> in one big proposal.
>
> I've also given up on integrating enums generically into it; as I don't
> think it's possible to do it in a similar enough way, and some extension to
> pattern matching would probably be better anyway.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] guard let x = x

[Dennis Lysenko via swift-evolution]

Gonna put in my 2 cents re shadowing being a source of bugs: I use explicit
self everywhere in my codebase and it pairs wonderfully with shadowing,
making the detailed example moot. As far as Dany's message, I think that's
the best way to go forward with an unwrap keyword--just make it work
exactly like if let x = x; not sure what other behavior was being
discussed. Another way to go, though, if we're really worried about
shadowing on mutable properties causing issues, would be to just have
nullity inference on constants, so if you said "let x = someNullableValue;
if x != nil { /* x would be inferred to be non-null here */ }". Kotlin does
this very, very successfully. (But my biggest reservation with such an
implementation in practice, in Kotlin, is that it only works for immutable
properties. Which is why I'm fully +1 on the unwrap statement. People are
going to shadow. Let them do it in a cleaner way.)

On Tue, Nov 1, 2016 at 9:47 PM Dany St-Amant via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Le 31 oct. 2016 à 17:44, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> >
> >> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> An alternative that would seem to satisfy some objections is to have a
> distinct "unwrap" statement--as in: "unwrap x else { ... }".
> >
> > I'd be against this alternative as it is doing the work of a guard
> statement (including the "must exit scope" rule) with a new keyword and
> unneeded redundancy.
> >
> > Adding "unwrap" is local. It performs one very common task with added
> safety (avoids unintended shadow effects) and introduces succinctness and
> clarity. In other words, it is a highly focused changed with a measurable
> benefit in use.
> >
> > Compare:
> >
> > * "Introduce the unwrap statement that acts like guard but is limited to
> optionals" creates unnecessary language verbosity.
> >
> > * "guard x else ", meaning "treat optional values differently than all
> other items in a conditional list", fails because it obscures rather than
> adds intent. Worse, it would lead to issues with Boolean optionals whose
> wrapped value is later used within the same condition.
> >
> > Xiaodi, you mentioned an alternative approach and I'd love a peek at
> what that is.
>
> Also with the 'guard unwrap', the following code make sense:
>
> guard unwrap x, x == 10 else { return }
>
> With a lone unwrap it would not.
>
> unwrap x, x == 10 else { return }
>
> I personally do not like shadowing, but a standalone 'unwrap!' could be of
> interest to those loving life in the shadows. Beside the shadowing itself,
> it should not be any worst than any of the other '!' usage. The feasibility
> of such depends of course on how the compiler manages its variable scoping.
>
> On further thought, if we were to make the, sorry bad word coming,
> code-breaking change to disallow legacy shadowing 'let x=x' and force the
> shadowing to be done exclusively via this 'unwrap' keyword, it could make
> it easier for projects/companies to ban shadowing.
>
> Dany
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

[Dennis Lysenko via swift-evolution]

FYI, the emoji bar with ctrl cmd space has worked that way since at the
very least El capitán, and I think as far back as mavericks.

Le lun. 31 oct. 2016 11:59, Haravikk via swift-evolution <
swift-evolution@swift.org> a écrit :

> On 31 Oct 2016, at 10:14, Alex Blewitt  wrote:
>
>
> On 29 Oct 2016, at 11:10, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Part of the problem for emoji is that the macOS special characters menu is
> so awkward to use; coincidentally I actually posted an enhancement request
> to the Apple bug reporter only yesterday asking for a more Spotlight-search
> like special characters selector. i.e- rather than the the awkward, tiny
> and hard to dismiss window something with immediate searching by relevant
> tags, either narrowing down for easy selection, or hitting enter for the
> top result.
>
>
> When typing you can use Control + Command + Space to bring up the same
> kind of emoji keyboard as on iOS; and it searches by name as well, so you
> can use the spotlight-like-search selector:
>
> [pump  ⓧ] [⠿⌘]
>   ⛽️ ⛽
>
>
> Screenshot in case the unicode characters don't survive:
>
> 
>
>
> Huh, this must be new on macOS Sierra? I'm still on El Capitan where it
> definitely does not work that way 
> If so it may be a reason to upgrade, as adding the winking emoji just
> there was a pain in the arse.
>
> In that case though I'm not sure what extra support Swift really needs, as
> key-combo plus type-to-search ought to be more than fast enough, no need to
> overburden auto-complete etc.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some clarity lost from the great renaming

[Dennis Lysenko via swift-evolution]

Agree on this particular case being unintuitive. I've come across a number
of such cases in Swift 3 but never really put too much thought into them.
Maybe you could just use for: UIControlState.normal until a resolution for
this is found (if there is one).

On Tue, Oct 18, 2016 at 10:32 PM Dennis Lysenko 
wrote:

> I think if it's one example like in this instance then a compiler
> directive to specify mapping if one does not already exist would be a more
> prudent option than changing the entire mapping.
>
> On Tue, Oct 18, 2016 at 9:51 PM Hooman Mehr via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is changing the mapping of Cocoa API considered a source breaking change
> or can we report such incidents as bugs if we think they don’t match API
> guidelines?
>
> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Tue Oct 18 2016, Brandon Knope  wrote:
>
> I meant to bring this up a bit ago but just came across it again.
>
> I find this to not read properly:
>
> button.setTitle("Test", for: .normal) //for normal what?
>
> The for argument is really only clear in meaning when you are typing
> it out and see that it is a UIControlState type. While reading it
> without this context is it as clear? .normal doesn't seem descriptive
> enough on its own.
>
> Contrast this with UISegmentedControl:
> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState:
> .normal, barMetrics:
> .default)
>
> Here the parameter labels are needed because there needs to be a
> distinction in the method between left and right. But here it is not
> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>
> So my question is: why was this not setTitle(forControlState:) or
> forButtonState, etc...?
>
>
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some clarity lost from the great renaming

[Dennis Lysenko via swift-evolution]

I think if it's one example like in this instance then a compiler directive
to specify mapping if one does not already exist would be a more prudent
option than changing the entire mapping.

On Tue, Oct 18, 2016 at 9:51 PM Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> Is changing the mapping of Cocoa API considered a source breaking change
> or can we report such incidents as bugs if we think they don’t match API
> guidelines?
>
> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Tue Oct 18 2016, Brandon Knope  wrote:
>
> I meant to bring this up a bit ago but just came across it again.
>
> I find this to not read properly:
>
> button.setTitle("Test", for: .normal) //for normal what?
>
> The for argument is really only clear in meaning when you are typing
> it out and see that it is a UIControlState type. While reading it
> without this context is it as clear? .normal doesn't seem descriptive
> enough on its own.
>
> Contrast this with UISegmentedControl:
> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState:
> .normal, barMetrics:
> .default)
>
> Here the parameter labels are needed because there needs to be a
> distinction in the method between left and right. But here it is not
> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>
> So my question is: why was this not setTitle(forControlState:) or
> forButtonState, etc...?
>
>
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

[Dennis Lysenko via swift-evolution]

Oops, completely missed about 57 messages in the meat of this discussion,
so apologies if what I said was already suggested.

On Sun, Sep 25, 2016 at 4:35 AM Dennis Lysenko 
wrote:

> Could take a page out of Kotlin's book:
>
> x.let { foo(it) } // default argument name that isn't $0
>
> IMO, this syntax looks better as a one liner than "if x? { foo(x) }".
>
> The edge case here, with foo and bar being optional-returning functions,
> becomes:
> (foo(42), bar(43)).let { x, y in foo(x, y) } // default argument "it" here
> is a tuple so you can't pass it directly to the function, therefore you
> have to name x and y explicitly
>
> In which case it should be abundantly clear to the reader that there is NO
> short-circuiting and both foo and bar are evaluated as a tuple before the
> "let" function is called on that tuple.
>
> On Sun, Sep 25, 2016 at 3:24 AM Justin Jia via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Sep 24, 2016, at 7:31 PM, Dany St-Amant  wrote:
>>
>> Reading some old threads...
>>
>> Le 16 août 2016 à 15:12, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> On Tue, Aug 16, 2016 at 12:14 PM, Justin Jia <
>> justin.jia.develo...@gmail.com> wrote:
>>
>>> I was trying to argue with reason. You kept stating your *opinion*. You
>>> still didn't explain *why*. For example, why "if statements can and
>>> function calls can't" and why "this severely violates user expectations"?
>>>
>>
>> These were not meant as expressions of opinion. Currently, in Swift, `if`
>> statements can short circuit and function calls cannot. Your proposal would
>> introduce short-circuiting where currently there can be none, and thus it
>> would severely violate user expectations.
>>
>>
>> Function calls can currently be short-circuited... if there's try and
>> throw involved.
>>
>> let z = try g(f1(a), f2(b), f3(c)) // Must be within do {} catch {}
>>
>> Assuming f1(), f2(), f3() can all throws, f2() is only called if f1() did
>> not throw, and f3() if neither f1() nor f2() threw. The behavior is/seems
>> to be: Pure left to right execution order regardless of throwing ability.
>>
>> If g() doesn't throw, the above (with exact same behavior) can be written
>> more verbosely and explicitly as:
>>
>> let y = g(try f1(a), try f2(b), try f3(c)) // Must be within do {} catch
>> {}
>>
>> Yet another way to do the call is:
>>
>> let x = try? g(f1(a), f2(b), f3(c)) // z is nil on throws
>>
>> So implementing something like what Justin is asking should fit within
>> Swift, as long as it follows the try short-circuit logic. However, the use
>> of a trailing question-mark to provide this functionality is not explicit
>> enough to my taste (and to my weakening eyesight). Could we reuse let but
>> with a question-mark? Or maybe guard.
>>
>>
>> Good point! Edge cases always exist.
>>
>> let z = g(let? f1(a), let? f2(b), let? f3(c))
>> // z is nil on fX() == nil, otherwise Optional(g()) just like try?
>> wrapping
>> // left to right short-circuit à la let z = try?
>>
>>
>> This sounds like a good idea. Moving the keyword to the front is more
>> explicit. But `let? f1(a)` seems a little bit weird to me.
>>
>> What about `let x = if? foo(x, y)` But… should we introduce `if!` as well?
>>
>> ```
>> func foo(x: Any, y: Any) { … }
>>
>> let x: Any? = nil
>> let y: Any? = nil
>> if? foo(x, y) // If x and y both can be unwrapped, execute foo().
>> if? foo(x?, y?) // Or if we want to be a little bit more clear, specify
>> which argument could be optional
>> ```
>>
>> ```
>> if! foo(x, y) // Will crash if nil is found.
>> if! foo(x!, y!) // To be more clear
>> ```
>>
>> Backward compatibility:
>>
>> ```
>> foo(x!, y!) // warning: add if! before the function
>> ```
>>
>> Though, this may ask for also supporting something like:
>>
>> let x = g(let? try? f1(a), let? try? f2(b), let? try? f3(c))
>>
>> This allow selective discard of throws, instead of a discard all of a
>> plain 'let x = try? ...'
>>
>>
>> Yes.
>>
>> Dany
>>
>> ... snip ...
>>>
>>
> On Aug 16, 2016, at 1:16 AM, Xiaodi Wu  wrote:
>>
>> On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu 
>> wrote:
>>
>>> On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia <
>>> justin.jia.develo...@gmail.com> wrote:
>>>
 I believe the core team has considered 99% of the ideas in the
 mailing list in the past, but it doesn’t mean we can’t discuss it, 
 right?

>>> .. snip ...
>>>

 Back to the original topic.

 I spent some time thinking and changed my mind again. I think
 solution 1 is most reasonable. It is consistent with if statements. 
 Instead
 of treating it as sugar for `if let`, we can treat it as sugar for 
 `guard`,
 which is much easy to understand and remember.

 -

 Below is the reason why I think 

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

[Dennis Lysenko via swift-evolution]

Could take a page out of Kotlin's book:

x.let { foo(it) } // default argument name that isn't $0

IMO, this syntax looks better as a one liner than "if x? { foo(x) }".

The edge case here, with foo and bar being optional-returning functions,
becomes:
(foo(42), bar(43)).let { x, y in foo(x, y) } // default argument "it" here
is a tuple so you can't pass it directly to the function, therefore you
have to name x and y explicitly

In which case it should be abundantly clear to the reader that there is NO
short-circuiting and both foo and bar are evaluated as a tuple before the
"let" function is called on that tuple.

On Sun, Sep 25, 2016 at 3:24 AM Justin Jia via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 24, 2016, at 7:31 PM, Dany St-Amant  wrote:
>
> Reading some old threads...
>
> Le 16 août 2016 à 15:12, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> On Tue, Aug 16, 2016 at 12:14 PM, Justin Jia <
> justin.jia.develo...@gmail.com> wrote:
>
>> I was trying to argue with reason. You kept stating your *opinion*. You
>> still didn't explain *why*. For example, why "if statements can and
>> function calls can't" and why "this severely violates user expectations"?
>>
>
> These were not meant as expressions of opinion. Currently, in Swift, `if`
> statements can short circuit and function calls cannot. Your proposal would
> introduce short-circuiting where currently there can be none, and thus it
> would severely violate user expectations.
>
>
> Function calls can currently be short-circuited... if there's try and
> throw involved.
>
> let z = try g(f1(a), f2(b), f3(c)) // Must be within do {} catch {}
>
> Assuming f1(), f2(), f3() can all throws, f2() is only called if f1() did
> not throw, and f3() if neither f1() nor f2() threw. The behavior is/seems
> to be: Pure left to right execution order regardless of throwing ability.
>
> If g() doesn't throw, the above (with exact same behavior) can be written
> more verbosely and explicitly as:
>
> let y = g(try f1(a), try f2(b), try f3(c)) // Must be within do {} catch {}
>
> Yet another way to do the call is:
>
> let x = try? g(f1(a), f2(b), f3(c)) // z is nil on throws
>
> So implementing something like what Justin is asking should fit within
> Swift, as long as it follows the try short-circuit logic. However, the use
> of a trailing question-mark to provide this functionality is not explicit
> enough to my taste (and to my weakening eyesight). Could we reuse let but
> with a question-mark? Or maybe guard.
>
>
> Good point! Edge cases always exist.
>
> let z = g(let? f1(a), let? f2(b), let? f3(c))
> // z is nil on fX() == nil, otherwise Optional(g()) just like try? wrapping
> // left to right short-circuit à la let z = try?
>
>
> This sounds like a good idea. Moving the keyword to the front is more
> explicit. But `let? f1(a)` seems a little bit weird to me.
>
> What about `let x = if? foo(x, y)` But… should we introduce `if!` as well?
>
> ```
> func foo(x: Any, y: Any) { … }
>
> let x: Any? = nil
> let y: Any? = nil
> if? foo(x, y) // If x and y both can be unwrapped, execute foo().
> if? foo(x?, y?) // Or if we want to be a little bit more clear, specify
> which argument could be optional
> ```
>
> ```
> if! foo(x, y) // Will crash if nil is found.
> if! foo(x!, y!) // To be more clear
> ```
>
> Backward compatibility:
>
> ```
> foo(x!, y!) // warning: add if! before the function
> ```
>
> Though, this may ask for also supporting something like:
>
> let x = g(let? try? f1(a), let? try? f2(b), let? try? f3(c))
>
> This allow selective discard of throws, instead of a discard all of a
> plain 'let x = try? ...'
>
>
> Yes.
>
> Dany
>
> ... snip ...
>>
>
 On Aug 16, 2016, at 1:16 AM, Xiaodi Wu  wrote:
>
> On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu 
> wrote:
>
>> On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia <
>> justin.jia.develo...@gmail.com> wrote:
>>
>>> I believe the core team has considered 99% of the ideas in the
>>> mailing list in the past, but it doesn’t mean we can’t discuss it, 
>>> right?
>>>
>> .. snip ...
>>
>>>
>>> Back to the original topic.
>>>
>>> I spent some time thinking and changed my mind again. I think
>>> solution 1 is most reasonable. It is consistent with if statements. 
>>> Instead
>>> of treating it as sugar for `if let`, we can treat it as sugar for 
>>> `guard`,
>>> which is much easy to understand and remember.
>>>
>>> -
>>>
>>> Below is the reason why I think this feature is important (quoted
>>> from another email).
>>>
>>> The problem with `if let` is you need to call the function inside {
>>> }.
>>>
>>> ```
>>> /* code 1 */
>>> if let x = x, let y = y {
>>> /* code 2, depends on x and y to be non-optional */
>>> let z = foo(x, y)
>>> if let z = z {
>>> 

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

[Dennis Lysenko via swift-evolution]

FWIW, I rely on typing `tableView` and looking at the autocompletions to
find delegate methods.

Not that that makes this a bad idea, and I'm not sure how many other
developers do that (although I imagine quite a few do). Just food for
thought.

On Mon, Jun 27, 2016 at 11:44 AM Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> I believe that renaming of Apple’s frameworks is not in the scope of
> swift-evolution; I think you’re supposed to file a radar.
>
> On Mon, Jun 27, 2016 at 9:54 AM Jerome ALVES via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi everyone,
>>
>> I can't find anything about Cocoa Delegate/Datasource protocol "Grand
>> Renaming" for Swift 3
>> Is something planned about this ?
>>
>> Because I find that actual names don't fit with Swift 3 API guidelines.
>>
>> For instance :
>>
>> func numberOfSectionsInTableView(_ *tableView*: UITableView) -> Int
>> func tableView(_ *tableView*: UITableView, numberOfRowsInSection
>> *section*: Int) -> Int
>> func tableView(_ *tableView*: UITableView, cellForRowAtIndexPath
>> *indexPath*: NSIndexPath) -> UITableViewCell
>> func tableView(_ *tableView*: UITableView, moveRowAtIndexPath
>> *sourceIndexPath*: NSIndexPath, toIndexPath *destinationIndexPath*:
>> NSIndexPath)
>>
>> func tableView(_ *tableView*: UITableView, heightForRowAtIndexPath
>> *indexPath*: NSIndexPath) -> CGFloat
>> func tableView(_ *tableView*: UITableView, didSelectRowAtIndexPath
>> *indexPath*: NSIndexPath)
>> ...
>>
>> could be renamed to *something* like this :
>>
>> func numberOfSections(in *tableView*: UITableView) -> Int
>> func numberOfRows(inSection *section*: Int, in *tableView*: UITableView)
>> -> Int
>> func cellForRow(at *indexPath*: NSIndexPath, in *tableView*: UITableView)
>> -> UITableViewCell
>> func moveRow(at *sourceIndexPath*: NSIndexPath, to *destinationIndexPath*
>> : NSIndexPath, in *tableView*: UITableView)
>>
>> func heightForRow(at *indexPath*: NSIndexPath, in *tableView*:
>> UITableView) -> CGFloat
>> func didSelectRow(at *indexPath*: NSIndexPath, in *tableView*:
>> UITableView)
>> ...
>>
>>
>>
>> Kind regards,
>>
>> Jérôme Alves
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Dennis Lysenko via swift-evolution]

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
carryover from Java. They show up in method signatures from
non-nullable-annotated Java, but you can't define a new method that takes
e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see
areas where IUOs are clearly useful (ViewControllers for instance) but
defining new functions that take implicitly unwrapped optionals makes no
sense. If you need to pass a IUO at the call site, you can define the
function taking a non-optional value and pass the IUO to that. There is no
use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin
where there is also inconsistency in the same vein. I see it simply as a
compromise that achieves the goal of keeping a useful feature but
discouraging its overuse by forbidding its use in places where its use
could confuse and snowball down the line into teaching developers worse
code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> Ok, I see - though I find myself using occasionally IUOs in Swift as well
> - e.g. when you can't use the default values because they depend on self,
> etc.
>
> Eliminating it just from method signatures IMHO brings an incosistency
> into the language. Why would you eliminate it only from method signatures -
> this proposal mentioned importing ObjC API in the beginning - why not then
> mark those properties all as optional as well? IUOs are scheduled to be
> removed completely once the language reaches a point where it can handle
> most scenarios otherwise...
>
> Try to imagine some APIs brought to Swift with default being nullable:
>
> /// Imported from
> public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
> NSSecureCoding, NSFastEnumeration {
>
>
> public var count: Int { get }
> public func objectAtIndex(idx: Int) -> AnyObject?
> public func indexOfObject(object: AnyObject?) -> Int
> public init()
> public init(objects: UnsafePointer, count cnt: Int)
> public init?(coder aDecoder: NSCoder?)
> }
>
> This doesn't make much sense - mostly objectAtIndex(_:).
>
> On Jun 27, 2016, at 8:35 PM, Saagar Jha  wrote:
>
> I think you’re mistaking the scope of the proposal. It’s simply removing
> IUOs in *function signatures*, not throughout the language.
>
> On Mon, Jun 27, 2016 at 11:31 AM Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> There are many useful cases for IUO in Swift - mostly when you have
>> variables that cannot be calculated at the point of calling super.init(),
>> but are guaranteed to be filled during initialization - i.e. during the
>> lifetime of the object, the value is nonnil, but may be nil for a short
>> period of time.
>>
>> Or @IBOutlets. Making all @IBOutlets optionals would make the code either
>> riddled with ! or shadowed locally re-declared instance members.
>>
>>
>> > On Jun 27, 2016, at 8:12 PM, Jean-Daniel Dupas 
>> wrote:
>> >
>> > Maybe we can prohibit it in Swift function declaration, and allow it
>> only when importing native code.
>> >
>> > As David, I don’t see any compelling reason to allow such construct in
>> Swift.
>> >
>> >> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >>
>> >> When you import ObjC code that has no nullability annotation, IUO make
>> sense since:
>> >>
>> >> - they can be checked against nil
>> >> - typically, most values in APIs are nonnull (looking at Foundation,
>> for example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark
>> entire regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
>> >>
>> >> Importing them as optionals would make it really hard to work with the
>> code - whenever you get a value, it's an optional, even in cases where it
>> makes no sense and adding ! to unwrap the optional is not a great solution.
>> And the other solution is to use guards everywhere.
>> >>
>> >> IMHO the IUO is a nice (temporary) solution for using un-annotated
>> code until it is. But the "pressure" should be applied on the ObjC code.
>> >>
>> >>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <
>> david.ronnqv...@gmail.com> wrote:
>> >>>
>> >>> I don’t know about the chances of getting approved, but I think this
>> is something worth discussing.
>> >>>
>> >>> It might just be my ignorance, but I can’t think of a good reason why
>> a function argument would be force unwrapped. Either it’s non-null and the
>> caller is expected to unwrap it or it’s nullable and the method is expected
>> to handle the nil value. So I’m positive to that part of the proposal.
>> >>>
>> >>> As to what we should do with the generated interfaces of Objective-C
>> code that hasn’t been annotated with nullability, I think that needs input
>> from more people to find the 

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Dennis Lysenko via swift-evolution]

My 2c:

This proposal is made more appealing to me because it is not simply a
'beginners will get confused' issue.

I have written tens of thousands of lines of Swift from Swift 1 to the
Swift 3 preview and I still can't shake occasionally accidentally capturing
`self` strongly when I, for example, assign a closure as a listener/action
to a UI component.

To spin off of Christopher's last email, my proposal is thus: we could
include the original proposal (without numbered addendums) and use tooling,
but have it alleviate the burden another way: have the tooling insert
`[strong self]` by default when autocompleting a block.

BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill
map statement. array.map { object in object.property } requires no explicit
capture since object is intuitively strongly captured there.

What do we think? Worth discussing?

On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>All object references used within a closure must unwrap successfully
>for the closure to execute.
>
> I agree with the logic of this proposal, but this is the confusing part or
> a part that I slightly disagree with.
>
> By this logic, the block won't be invoked if all captured variables can't
> be unwrapped, which is definitely confusing to the newcomer (to whom this
> is partially targetted as you've mentioned) if he puts a breakpoint in it
> and doesn't get executed even when he's explicitely invoking it somewhere.
>
> On the other hand, when it crashes, it gives him some idea that
> something's wrong.
>
>
> Tooling could alleviate some of this mystery. For example:
>
> 1) In Xcode and other GUIs, closures that will not be executed could be
> greyed-out, perhaps with the reason overlaid on the closure perhaps this
> would only happen when a breakpoint was set within the closure. Perhaps the
> app could break on the on breakpoints within non-executing closures and
> notify the user that the closure did not execute.
>
> 2) Debugger console commands could be added to describe the execution
> state of closures in scope and closure variables.
>
> 3) Debug apps could bottleneck all closures through a function that that
> can be break-pointed. Breakpoints could be edited to filter on specific
> closures.
>
> 4) Some runtime switches could be added to enable verbose login modes for
> closures.
>
> I don’t think that this is an insurmountable problem. There are many
> features of modern applications that are difficult to debug.
>
>
>
>
>
>
> I believe that these are safe, sensible and understandable rules that will
> eliminate the need for capture lists for many closures. What do you think?
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Guaranteed closure execution

[Dennis Lysenko via swift-evolution]

Just curious, is there a deeper-than-semantic difference between a
@noescape(once) closure and an inlined closure?

On Sun, Apr 24, 2016, 5:58 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Andrew,
>
> I'm rather embarrassed: the initial design of this proposal was based on a
> modifier of @noescape:
>
> func f(@noescape(once) closure: () -> ()) { … }
>
> But since the 0049 proposal has been accepted (
> https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md),
> @noescape is no longer an argument qualifier, but a type attribute.
>
> The `once` discussed here can not be part of the type: if noescape can
> understandably be part of the type, the fact that a function guarantees it
> will call a closure once is a quality of that function, not of the closure.
>
> So the proposed @noescape(once) syntax is now confusing as it would mix a
> type attribute and a argument qualifier.
>
> I don't quite know how to escape this:
>
> // two @ signs
> func f(@noescape @once closure: () -> ()) { … }
>
> // Implies @noescape
> func f(@once closure: () -> ()) { … }
>
> I'd like advice from competent people before I would attempt a rewrite of
> the proposal.
>
>
> Hi Gwendal,
>
> I don’t think that the movement of @noescape affects the approach: I’d
> suggest that a proposal (e.g. Felix’s) go with:
>
> func f(closure: @noescape(once) () -> ()) { … }
>
> The semantics are clear: the closure is guaranteed to be called exactly
> once on all normal and “throw” paths.  Paths that do not return in either
> of those ways (e.g. a call to abort) do not need to call the closure.
>
> IMO, this is a small scope proposal that is likely to be accepted.
>
> -Chris
>
>
>
> Gwendal Roué
>
> Le 10 avr. 2016 à 23:26, Andrew Bennett  a écrit :
>
> Sorry I missed that scrolling back through the history, that proposal
> looks great. It doesn't look like it has been submitted as a pull request
> to swift-evolution yet though.
>
> On Sunday, 10 April 2016, Gwendal Roué  wrote:
>
>> Felix Cloutier already wrote one:
>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>
>> Do you think it needs to be rewritten?
>>
>> Gwendal Roué
>>
>> Le 10 avr. 2016 à 14:56, Andrew Bennett  a écrit :
>>
>> Hi, not beyond this thread that I have seen. I think it's worth you
>> summarizing this thread in a formal proposal and putting it up for
>> discussion or submitting it as a PR :)
>>
>> On Sunday, 10 April 2016, Gwendal Roué  wrote:
>>
>>> Hello all,
>>>
>>> I was wondering if this topic had evolved in anyway since its original
>>> introduction.
>>>
>>> @noescape(once) would still be a useful addition to the language!
>>>
>>> Gwendal Roué
>>>
>>>
>>>
>>> Le 3 févr. 2016 à 22:21, Félix Cloutier via swift-evolution <
>>> swift-evolution@swift.org> a écrit :
>>>
>>> I updated the proposal to address some concerns. It can be found at:
>>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>>
>>> Things that changed:
>>>
>>>
>>>- It now says that the closure must be called on code paths where
>>>the function throws;
>>>- you can have multiple @noescape(once) parameters but they can't
>>>make assumptions from one another.
>>>
>>>
>>> I'm not 100% convinced that forcing a call on code paths that throw is
>>> always desirable. I've changed it because Chris's support probably means
>>> that the feature has better chances of making it, but I'm not convinced
>>> yet. If throwing allows me to return without calling the closure, I can
>>> write this:
>>>
>>> do {
>>> let foo: Int
>>> try withLock(someLock, timeout: 0.5) {
>>> foo = sharedThing.foo
>>> }
>>> } catch {
>>> print("couldn't acquire lock fast enough")
>>> }
>>>
>>> which would be kind of messy if instead, the closure needed a parameter
>>> to tell whether the lock was acquired or not when it runs.
>>>
>>> Félix
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Dennis Lysenko via swift-evolution]

Everyone,

The sticking point here is that xcode generates the first syntax
automatically.

Simply filing a radar about this would be useless, so I believe the
original proposal is meant to sort-of "light a fire" under the Xcode team;
by introducing a new language feature they would be forced to support it.

Personally, I think it should just be fixed in Xcode as well, but it's not
that simple.

On Tue, Jan 5, 2016, 8:35 AM Jérôme Duquennoy 
wrote:

> Hi everybody,
>
> I do agree with Kevin : trailing closures is only a possibility offered by
> the language, you are not forced to use it.
> In the case you show, I agree that the second syntax is more readable than
> the first one. Good news is : it does compile :-).
>
> I think adding a specific keyword or annotation to locally forbid trailing
> closure would add complexity to the language for no real advantage.
>
> -1 for me thus.
>
> Jerome
>
>
>
> On 04 Jan 2016, at 19:52, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What's the point of this? What problem does it solve? If you don't want a
> trailing closure, just don't use trailing closure syntax. I don't see what
> benefit there is in explicitly annotating the function to disallow trailing
> closure syntax with it; just because you don't want to use trailing closure
> syntax doesn't mean nobody should be able to use it. And other people using
> it shouldn't affect you.
>
> -Kevin Ballard
>
> On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:
>
> Hi, All:
> trailing closure is good for most cases, but sometimes it is also make
> code unclear, for example:
>
> UIView.animateWithDuration(0.3, animations: { () -> Void in
> // animation code here
> }) { (Bool) -> Void in
> // completion code here
> }
>
> the label been removed and the code also not aligned well.
> I would like to write like this:
>
> UIView.animateWithDuration(0.3,
>
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )
>
> It is possible, just every time you have to write it manually. It’s a
> little wast.
> So I have a thought, since we already know this function is not well suit
> for trailing
> closure, can we add a attribute to disable it, for example:
>
> extensionUIView {
>
> @disable_trailing_closure
> public static func animateWithDuration(duration:NSTimeInterval,
> animations:()->Void, completion:()->Void) {
> // implementations ...
> }
> }
>
> I also found another one have issue for this too. link:
> http://www.natashatherobot.com/swift-trailing-closure-syntax/
> what do you think?
>
> Best Regards
>
> ChenYungui
>
> *___*
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Failable Initializer Suggestion

[Dennis Lysenko via swift-evolution]

My initial stance several months ago was that initializers should throw
instead of returning nil, but I've changed it as a result of the error
handling rationale (same document as Chris linked).

Specifically this section, taken from ErrorHandlingRationale.rst:

Simple domain errors

A simple domain error is something like calling String.toInt() on a string
that isn't an integer. The operation has an obvious precondition about its
arguments, but it's useful to be able to pass other values to test whether
they're okay. The client will often handle the error immediately.

Conditions like this are best modeled with an optional return value. They
don't benefit from a more complex error-handling model, and using one would
make common code unnecessarily awkward. For example, speculatively trying
to parse aString as an integer in Java requires catching an exception,
which is far more syntactically heavyweight (and inefficient without
optimization).

Because Swift already has good support for optionals, these conditions do
not need to be a focus of this proposal.

In constructors, the most common (and I would posit the only common) case
of error would be a simple domain error, so failable initializers suffice.

On Tue, Jan 5, 2016 at 12:52 AM Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for keeping failable initializers. Error handling should be reserved
> for errors and not be used for control flow or logic.
>
> -Thorsten
>
> Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
>
> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I just found that the design of failable initializer is redundant in Swift
> 2. Because native error handling already has been introduced in Swift 2,
> and failable initializer indeed could be achieved by following codes:
>
>
> I’d be opposed to removing failable initializers.  Failable inits
> introduce a symmetry into the language for initializers, which make them
> possible to do (almost) all of what you can do with a normal method.  This
> capability is key for them to be able to replace “factory” static methods,
> which allows Swift to offer a consistent initialization pattern for clients
> of types.
>
> If we forced people to use error handling for anything that could return
> nil, then things like String to Int conversions would most likely not use
> initialization syntax.
>
> Besides that, over use of error handling waters it down and makes it less
> valuable in itself.  For more information on this, please see the design
> discussion for error handling:
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Dennis Lysenko via swift-evolution]

Thorsten,

Not that I disapprove (Kotlin does the same and it's great), the precedent
seems to have already been set in people's minds that there won't be any
kind of implicit type narrowing and I predict a fair few will respond with
"You can already do that with optional binding, and I'm uncomfortable
seeing a variable change type in an inner scope" even though shadowing
achieves exactly the same aim. The same happened the last time that type
narrowing was mentioned.


On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Ceylon has type narrowing (not only for optional unwrapping but for type
> checks as well):
> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>
> It always struck me as quite natural to do this.
>
> -Thorsten
>
> Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution <
> swift-evolution@swift.org>:
>
>
> Whoops, errant button tap.
>
> I've always thought that,
>
> if let foo = foo? {
>
> }
>
> makes more sense than
>
> if let foo = foo {
>
> }
>
> as the ? indicates that you are unwrapping the optional and then assigning
> it to the new variable.
>
> The current syntax must seem incomprehensible/redundant to those new to
> Swift. This obviously doesn't help with the verbosity at all, but it seems
> to be more consistent with ? being the operator for unwrapping.
>
> Of course there is also the current optional pattern matching syntax:
>
> if case let foo? = foo {
>
> }
>
> This accomplishes the same thing and is somewhat less perplexing than "if
> let foo = foo", but must still be baffling to a new user.
>
> You could even have:
>
> if foo? {
> foo.blah()
> }
>
> Which would not create a shadow local variable but would have the same
> semantics as
>
> foo?.blah()
>
> in that is just providing conditional access to the variable if it's not
> .None. Not sure if this direct access is desired as it is still magical
> scoped type manipulation without declaring a new variable.
>
>
> Tyler
>
>
> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier <cloutierty...@aol.com> wrote:
>
> I've always thought that,
>
> if let foo = foo? {
>
> }
>
> makes more sense than
>
> if let foo = foo {
>
> }
>
> as the ? indicates that you are unwrapping the optional and then assigning
> it to the new variable
>
> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve only read the last couple of posts but has anybody already suggested
> using something like this:
>
> if let foo! {
>   // code that uses foo
> }
>
> People already know that the ! is unwrapping a value and that let is
> defining a new constant. So why not combine those two?
> Alternatively it could also be:
>
> if let foo? {
>   // code that uses foo
> }
>
> What do you think?
>
> – Cihat
>
> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution <
> swift-evolution@swift.org>:
>
>
> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was going to suggest something similar (a hard naming problem also):
>
> if has foo {
> // foo is now unwrapped and non-optional
> }
>
> guard has foo else { return }
>
> Does the same thing as `let foo = foo` in practice, but places it in a
> somewhat different mental model. Instead of unwrapping and immediately
> assigning to a new constant with the same name (which just looks kind of
> silly, like some magic voodoo ritual), it sort of asserts that we “have”
> foo (i.e. it’s not nil), and therefore from that point it can just be
> treated as non-optional.
>
> IMHO this, although introduces a new keyword, makes more sense than trying
> to reuse “let” in a context where it seems nonsensical. Perhaps this would
> be closer to Swift’s goals, by reducing very common boilerplate, but
> without harming clarity in a way adding a new meaning to “let” would.
>
> Curious to hear Chris Lattner’s opinion :-)
>
>
> IANACL (I am not a Chris Lattner) but, FWIW, several of us are
> uncomfortable with the idea that a single declared property might have
> different static types in different regions of code.
>
>
> — Radek
>
> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What if we made the keyword "unwrap"?
>
> if unwrap someViewController {
> // now there is a shadowing nonoptional (unwrapped) variable of the same
> name only withi

Re: [swift-evolution] Better syntax for deferred?

[Dennis Lysenko via swift-evolution]

Deferring at the end of the function removes the ability to defer actions
on variables introduced in an inner scope.

On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I have the terrible feeling something is wrong with my posts so that they
> get caught by spamfilters or similar…
>
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to
> archive.
>
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] Scala updated equivalent

[Dennis Lysenko via swift-evolution]

+1. This is very functional. Need to drill home the point that arrays have
copy semantics in the intro swift docs though, if we start going in this
direction.

On Tue, Dec 22, 2015, 7:12 AM Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

> Moving to swift-evolution.
>
> On Tue, Dec 22, 2015 at 2:42 AM, Alexandre Lopoukhine via swift-dev
>  wrote:
> > Hello everyone!
> >
> > What do you all think about adding the equivalent of Scala’s update
> method to collections that have the insert() func? This would likely take
> the form of:
> >
> > public func inserted(newElement: Self.Generator.Element, atIndex i:
> Self.Index) -> Self {
> > var modified = self
> > modified.insert(newElement, atIndex: i)
> > return modified
> > }
> >
> > I’ve had to do this manually quite a lot in my various programs, where
> I’ve had to return an array or dictionary with just one element modified,
> and I have a feeling that I am not alone. I think that this is quite a
> natural way to go about things, and the addition would cut down on
> boilerplate code.
> >
> > — Sasha
> >
> > P.S. Alternatives could be “.withInserted(el, atIndex: i)” or “.with(el,
> insertedAtIndex: i)"
> > ___
> > swift-dev mailing list
> > swift-...@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] function "return" optional keyword.

[Dennis Lysenko via swift-evolution]

This is very nice for writing lazy var definitions and single-line computed
properties as well. +1 from me.

On Sat, Dec 19, 2015, 8:30 AM Craig Cruden via swift-evolution <
swift-evolution@swift.org> wrote:

>
> When writing short functional code in a function it would be nice if the
> return keyword were an optional keyword.
>
> Just return the last evaluated expression.
>
>
> i.e.
>
> func flipFunc(arg1: T, arg2: U) -> (U, T) {
> (arg2, arg1)
> }
>
>
> The keyword return would still be there for breaking out of a function.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Dennis Lysenko via swift-evolution]

What if we made the keyword "unwrap"?

if unwrap someViewController {
// now there is a shadowing nonoptional (unwrapped) variable of the same
name only within this scope, boiling down to simple syntactic sugar for
optional binding and it is fairly clear.
}

On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution <
swift-evolution@swift.org> wrote:

> As much fun as it to example with foo, I would argue the opposite when you
> use some real world variable names:
>
> if let someInterestingViewConroller = someInterestingViewConroller {
> }
>
> vs
>
> If let someInterestingViewConroller {
> }
>
> We know what let does and it should be enough to impart the necessary
> information for this statement.
>
> When it comes to newcomers I think you'd be hard pressed to find somebody
> who'd be able to understand either form without teaching; so not losing
> much there.
>
>
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve had similar ideas to this. Instead of ditching the if let syntax
> altogether, another approach would be to use the existing name if no new
> name is given, so that this code:
>
> if let foo = foo { /* use foo */ }
>
> could become this code:
>
> if let foo { /* use foo */ }
>
> In both cases, foo is non-optional inside the braces. If you gave it
> another name with the if let syntax, that would work as it does today.
>
>
> Hi Jeff,
>
> This is commonly requested - the problem is that while it does help reduce
> boilerplate, it runs counter to the goal of improving clarity.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Dennis Lysenko via swift-evolution]

Disagree. Short names are less descriptive and less readable. And saying
"shadowing is bad" without any argument is just silly for a mailing list.

On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I prefer
>
> if let vc = someInterestingViewConroller {
> vc.doSomething()
> }
>
> - Explicit is better than implicit
> - shadowing is bad
> - now there's no ambiguity about how to change the original property.
>
> Therefore I'm -1 on any proposal that hides explicit name binding and/or
> increases shadowing, including let foo and unwrap foo.
>
>
> +1 to that.  IMO re-using the same name for the unwrapped version of an
> optional variable does not help readability, and I don't want to encourage
> it.  In a localized context like this, a short name is often better anyway
> as it declutters the code inside the block.
>
>
> On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> As much fun as it to example with foo, I would argue the opposite when
>> you use some real world variable names:
>>
>> if let someInterestingViewConroller = someInterestingViewConroller {
>> }
>>
>> vs
>>
>> If let someInterestingViewConroller {
>> }
>>
>> We know what let does and it should be enough to impart the necessary
>> information for this statement.
>>
>> When it comes to newcomers I think you'd be hard pressed to find somebody
>> who'd be able to understand either form without teaching; so not losing
>> much there.
>>
>>
>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I’ve had similar ideas to this. Instead of ditching the if let syntax
>> altogether, another approach would be to use the existing name if no new
>> name is given, so that this code:
>>
>> if let foo = foo { /* use foo */ }
>>
>> could become this code:
>>
>> if let foo { /* use foo */ }
>>
>> In both cases, foo is non-optional inside the braces. If you gave it
>> another name with the if let syntax, that would work as it does today.
>>
>>
>> Hi Jeff,
>>
>> This is commonly requested - the problem is that while it does help
>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>
>> -Chris
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> -Dave
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ternary operator ?: suggestion

[Dennis Lysenko via swift-evolution]

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause
people to be interested in this particular proposal and I don't think we
can reconcile all of them. For example, I think that "collapsing an if
statement into one line" isn't a good enough reason to introduce the
clutter and potential for abuse of the original ternary syntax into a
codebase, so I generally float the idea to ban it from projects I'm
involved in as soon as I see it pop up in one. At the same time, there seem
to be people who are enamored with the concept, and maybe instead they talk
in this thread because they want a way to condense a switch statement into
one line. And still others think that there is no rush to think about
getting rid of ternary, unless we come up with something equally concise or
with significant advantages to warrant removing it (all valid points).

I'm not *against* Paul's idea, but if it matters at all (i.e. if you are
worried other people will think like me), if this syntax is released, I
will most likely float the idea of opting out of it immediately to my
project collaborators.

While interesting for quick, proof of concept coding sessions, it already
has some of the readability and abusability disadvantages already present
in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning fully-qualified
(and indented) statements into expressions.

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > It's a nice, consistent proposal, but I don't feel like this solves any
> of the complaints about the existing ternary operator:
> >
> > - It's not obvious what it does when you first learn it.
> > - The '?' doesn't have anything to do with Optionals.
> >
> > It is a way to put 'switch' into an expression. I'm not a fan of the two
> different colons, but that's "just" syntax.
>
> +1 to all that
>
> > Jordan
> >
> >> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> All,
> >>
> >> I think, I finally might have the answer to improving ternary, with
> such a bold statement come some pretty high expectations but I think, I
> might actually have done it this time :-)
> >>
> >> I am calling it the Demux Expression, it builds on the benefits of
> ternary and switch while improving on those.
> >>
> >> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
> >>
> >> This is a first draft, thanks in advance for feedback!
> >>
> >> - Paul
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -Dave
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[Dennis Lysenko via swift-evolution]

Charles,

While I agree it's unfortunate that there isn't much interop between
ErrorType and NSError, the decision from the core team to make ErrorType an
empty protocol seems to have been a premeditated one. I would love to have
someone on the core team respond here in my stead, but I'll try and present
my side of it.

I have a lot of errors that come up internally in my app's workings. I
subscribe to Swift's error handling rationale regarding recoverable errors.
For example, my internal networking library has a NoInternetError which
never needs to be presented using built-in cocoa error presentation, but
instead has a different presentation scheme for each different context
(e.g. if it happened while loading a tableview, it shows up as the
placeholder text. if it happened in response to a user action, it displays
an alert.) I, therefore, strongly disagree with adding any extra members to
the ErrorType protocol: it's cruft that will never be of use to me.

Now, this is the part that I'm not sure about and I might be corrected by
someone from the core team: It seems that part of the rationale for
introducing the general ErrorType is to move *away* from NSError. NSError
is antiquated and carries information that is often not even used (take a
survey of 100 swift programmers, and maybe 40 of them will care to tell you
what an error domain is).

A lot of this probably hinges on typed `throws` annotations as well; if we
get those, then you never have to catch general ErrorType unless you wrote
a function to throw general ErrorType, so you could make all your error
types conform to a custom protocol with all this NSError-conformant info in
it without worrying about static dispatch.

On Sat, Dec 19, 2015 at 10:50 PM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> This is a bit of a pre-proposal; I wanted to bounce some ideas off the
> community before writing up a formal proposal, to see how people felt about
> this.
>
> The Problem:
>
> Swift introduces the very nifty ErrorType protocol, which, if implemented
> as an enum, allows one to associate arguments with the specific error cases
> with which they are relevant, as in this example:
>
> enum MyError: ErrorType {
> case JustFouledUp
> case CouldntDealWithFile(url: NSURL)
> case CouldntDealWithSomeValue(value: Int)
> }
>
> This is great, because it ensures that the file-related error will always
> have a URL object, whereas it won’t be included in the cases where it is
> irrelevant.
>
> Unfortunately, the Cocoa APIs needed to display an error object to the
> user all take NSErrors, and the conversion from other ErrorTypes to
> NSErrors is not very good; using “as NSError” to convert a MyError will
> result in something that has all of the associated values removed, and the
> message displayed to the user will be a cryptic and not particularly
> user-friendly “MyError error 1” rather than something more descriptive. One
> can define an “toNSError()” method on one’s own error type that will
> properly propagate the NSError’s userInfo dictionary such that it will be
> displayed in a more meaningful way:
>
> enum MyError: ErrorType {
> case JustFouledUp
> case CouldntDealWithFile(url: NSURL)
> case CouldntDealWithSomeValue(value: Int)
>
> func toNSError() -> NSError {
> var userInfo = [String : AnyObject]()
> let code: Int
>
>
> switch self {
> case .JustFouledUp:
> userInfo[NSLocalizedFailureReasonErrorKey] = "Something
> fouled up!"
> code = 0
> case let .CouldntDealWithFile(url):
> userInfo[NSLocalizedFailureReasonErrorKey] = "Something went
> wrong with the file \(url.lastPathComponent ?? "(null)")."
> userInfo[NSURLErrorKey] = url
> code = 1
> case let .CouldntDealWithSomeValue(value):
> userInfo[NSLocalizedFailureReasonErrorKey] = "This value
> isn't legit for some reason: \(value)"
> code = 2
> }
>
>
> return NSError(domain: "MyError", code: code, userInfo: userInfo)
> }
> }
>
> However, since this method will only be invoked if called explicitly, one
> has to make sure to include .toNSError() every time when throwing an error
> object, or else it will not display properly; one can never just throw a
> MyError object. This is error-prone (no pun intended), and also prevents
> things like making the error conform to Equatable and comparing it against
> an ErrorType we received from some other method.
>
> I propose an addition to the ErrorType protocol, provisionally entitled
> “toNSError()”, but which another name could be given if something else is
> determined to be more appropriate. This method would be called by the
> system whenever “as NSError” is called on something that implements
> ErrorType. While this method would be added to the protocol, a default
> implementation would be provided in an extension, so that implementers of
> ErrorType would 

Re: [swift-evolution] Brace syntax

[Dennis Lysenko via swift-evolution]

Also, Ruby has braces, though it is generally stylistically suggested to
only use them for inline blocks (arr.map { |x| x.name.chars.first }) and
when you don't use braces, you use even more verbose `do`/`end` syntax.

I don't know many people who have experienced a large variety (8+?) of
programming languages and prefer Python's forced indentation, but that's
just a point of style. Generally, I agree with all the stated points about
why braces are used, and Swift really seems to have been built with them in
mind.

On Sat, Dec 19, 2015 at 9:24 PM Félix Cloutier 
wrote:

> Python started in 1990 and Ruby started in 1995. Java started in 1996; C#
> in 2000; Go in 2010. These languages all use braces and are more recent
> than Python and Ruby. ALGOL 60, where 60 stands for 1960, didn't use braces
> either.
>
> To me, that's basically a fashion point. Given that this doesn't seem to
> open any new possibility over what we have, I wouldn't be in favor of it.
>
> > Le 19 déc. 2015 à 20:39:06, Alexander Regueiro via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > Has anyone considered removing braces from the Swift language? The main
> alternative would be indentation-based scoping like in Python or Ruby.
> There already seems to be a general emphasis on conciseness,  lack of
> redundancy, and a modern syntax. e.g. semicolons are not required for
> single-line statements; brackets have been removed from if/for/while
> expressions, compared to C-style syntax. So, why not go the whole way in
> breaking the C-style connection? The present syntax seems to be shunning C,
> but only slightly.
> >
> > Thoughts?
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Dennis Lysenko via swift-evolution]

Actually, Curt, not that I'm in favor of this proposal, but you inspired an
interesting thought--I think that if extensions were more powerful (e.g.
stored properties), then having closed classes by default might not be such
a big deal. What's the difference between using a `MyViewController`
subclass throughout your app to hack around Cocoa's limitations and writing
an extension for UIViewController to use app-wide? The only significant
difference would probably be a couple fewer hackarounds in the
UIViewController case.

Of course, it would break a lot of existing code *without a way to
automatically migrate it*. That's a deal breaker for me.

On Sat, Dec 19, 2015 at 10:09 PM Curt Clifton via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm not sure how many minuses I have to give, but I'd give them all to
> this proposal.
>
> Anyone who tries to ship products on release day of Apple's operating
> system updates spends most of August and September writing horrible hacks
> so that their users are insulated from OS bugs as much as possible. All
> software has bugs, frameworks included. Please don't take away our tools
> for working around those bugs. Making classes final by default assumes a
> level of perfection on the part of framework developers that is not
> achievable.
>
> Yes, subclassing a class that wasn't designed to be subclassed has serious
> risks. Thoughtful developers sometimes take on those risks in order to
> serve their customers.
>
> Frankly, I think having `final` in the language at all is a mistake. While
> I agree that we should prefer composition to inheritance*, declaring things
> final is hubris. The only reasonable use case I've seen is for
> optimization, but that smacks of developers serving the compiler rather
> than the converse. Bringing an analog of NS_REQUIRES_SUPER to Swift would
> be most welcome; that's as far as I'd go down the path of dictating
> framework usage.
>
> Cheers,
>
> Curt
>
> *- and am thrilled with the property behaviors proposal for this use case
>
>
> On Dec 17, 2015, at 5:55 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 17, 2015, at 5:41 PM, Rod Brown via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My opinion is -1 on this proposal. Classes seem by design to intrinsically
> support subclassing.
>
> What if one framework provider thinks “you won’t need to subclass this
> ever” but didn’t realise your use case for doing so, and didn’t add the
> keyword? When multiple developers come at things from different angles, the
> invariable situation ends with use cases each didn’t realise. Allowing
> subclassing by default seems to mitigate this risk at least for the most
> part.
>
>
> Frameworks change, and if the framework author didn't anticipate your use
> case for subclassing, they almost certainly aren't going to anticipate it
> while evolving their implementation and will likely break your code. Robust
> subclassability requires conscious design just like all other aspects of
> API design.
>
> -Joe
>
> I think this definitely comes under the banner of “this would be nice”
> without realising the fact you’d be shooting yourself in the foot when
> someone doesn’t add the keyword in other frameworks and you’re annoyed you
> can’t add it.
>
>
> On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Does it seem like there's enough interesest in this proposal? If so, what
> would be the next steps? Should I go ahead and create a PR on the evolution
> repo, describing the proposal version that Joe suggested, with classes
> closed for inheritance by default outside of a module?
>
> Thanks!
>
> On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I understand the rationale, I just disagree with it.
>>
>> IMO adding a keyword to state your intention for inheritance is not a
>> significant obstacle to prototyping and is not artificial bookkeeping.  I
>> really don't understand how this would conflict with "consequence-free"
>> rapid development.  It is a good thing to require people to stop and think
>> before using inheritance.  Often there is a more appropriate alternative.
>>
>> The assumption that it is straightforward to fix problems within a module
>> if you later decide you made a mistake is true in some respects but not in
>> others.  It is not uncommon for apps to be monolithic rather than being
>> well factored into separate modules, with many developers contributing and
>> the team changing over time.  While this is not ideal it is reality.
>>
>> When you have the full source it is certainly *possible* to solve any
>> problem but it is often not straightforward at all.  Here is an example of
>> a real-work scenario app developers might walk into:
>>
>> 1) A class is developed without subclassing in mind by one developer.
>> 2) After the original developer is gone another developer adds some

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[Dennis Lysenko via swift-evolution]

Sorry, got a little excited in answering and just re-read the proposal.
Ignore the part of "extra cruft", since I'll never have to see it unless I
want to override it. I thought that the static dispatch bit later on in the
proposal implies that that wouldn't work so well, but I might have misread.

On Sun, Dec 20, 2015 at 12:00 AM Dennis Lysenko 
wrote:

> Charles,
>
> While I agree it's unfortunate that there isn't much interop between
> ErrorType and NSError, the decision from the core team to make ErrorType an
> empty protocol seems to have been a premeditated one. I would love to have
> someone on the core team respond here in my stead, but I'll try and present
> my side of it.
>
> I have a lot of errors that come up internally in my app's workings. I
> subscribe to Swift's error handling rationale regarding recoverable errors.
> For example, my internal networking library has a NoInternetError which
> never needs to be presented using built-in cocoa error presentation, but
> instead has a different presentation scheme for each different context
> (e.g. if it happened while loading a tableview, it shows up as the
> placeholder text. if it happened in response to a user action, it displays
> an alert.) I, therefore, strongly disagree with adding any extra members to
> the ErrorType protocol: it's cruft that will never be of use to me.
>
> Now, this is the part that I'm not sure about and I might be corrected by
> someone from the core team: It seems that part of the rationale for
> introducing the general ErrorType is to move *away* from NSError. NSError
> is antiquated and carries information that is often not even used (take a
> survey of 100 swift programmers, and maybe 40 of them will care to tell you
> what an error domain is).
>
> A lot of this probably hinges on typed `throws` annotations as well; if we
> get those, then you never have to catch general ErrorType unless you wrote
> a function to throw general ErrorType, so you could make all your error
> types conform to a custom protocol with all this NSError-conformant info in
> it without worrying about static dispatch.
>
> On Sat, Dec 19, 2015 at 10:50 PM Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This is a bit of a pre-proposal; I wanted to bounce some ideas off the
>> community before writing up a formal proposal, to see how people felt about
>> this.
>>
>> The Problem:
>>
>> Swift introduces the very nifty ErrorType protocol, which, if implemented
>> as an enum, allows one to associate arguments with the specific error cases
>> with which they are relevant, as in this example:
>>
>> enum MyError: ErrorType {
>> case JustFouledUp
>> case CouldntDealWithFile(url: NSURL)
>> case CouldntDealWithSomeValue(value: Int)
>> }
>>
>> This is great, because it ensures that the file-related error will always
>> have a URL object, whereas it won’t be included in the cases where it is
>> irrelevant.
>>
>> Unfortunately, the Cocoa APIs needed to display an error object to the
>> user all take NSErrors, and the conversion from other ErrorTypes to
>> NSErrors is not very good; using “as NSError” to convert a MyError will
>> result in something that has all of the associated values removed, and the
>> message displayed to the user will be a cryptic and not particularly
>> user-friendly “MyError error 1” rather than something more descriptive. One
>> can define an “toNSError()” method on one’s own error type that will
>> properly propagate the NSError’s userInfo dictionary such that it will be
>> displayed in a more meaningful way:
>>
>> enum MyError: ErrorType {
>> case JustFouledUp
>> case CouldntDealWithFile(url: NSURL)
>> case CouldntDealWithSomeValue(value: Int)
>>
>> func toNSError() -> NSError {
>> var userInfo = [String : AnyObject]()
>> let code: Int
>>
>>
>> switch self {
>> case .JustFouledUp:
>> userInfo[NSLocalizedFailureReasonErrorKey] = "Something
>> fouled up!"
>> code = 0
>> case let .CouldntDealWithFile(url):
>> userInfo[NSLocalizedFailureReasonErrorKey] = "Something went
>> wrong with the file \(url.lastPathComponent ?? "(null)")."
>> userInfo[NSURLErrorKey] = url
>> code = 1
>> case let .CouldntDealWithSomeValue(value):
>> userInfo[NSLocalizedFailureReasonErrorKey] = "This value
>> isn't legit for some reason: \(value)"
>> code = 2
>> }
>>
>>
>> return NSError(domain: "MyError", code: code, userInfo: userInfo)
>> }
>> }
>>
>> However, since this method will only be invoked if called explicitly, one
>> has to make sure to include .toNSError() every time when throwing an error
>> object, or else it will not display properly; one can never just throw a
>> MyError object. This is error-prone (no pun intended), and also prevents
>> things like making the error conform to Equatable and comparing it against

Re: [swift-evolution] Proposal: Python's indexing and slicing

[Dennis Lysenko via swift-evolution]

Dave, perhaps we could use "^" as an anchor point for the start index and $
as the anchor point for the end index? It's familiar to anyone who knows a
bit of regex, and all vim users. My main worry would be ^ is already infix
xor operator.

On Fri, Dec 18, 2015 at 5:43 PM Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> I would like to avoid what you currently have to do for iterating a
> subcontainer.
>
> for a in container[0..container.count-4] {
> // do something.
> }
>
> The slicing syntax would certainly help in these common situations. Maybe
> there are easy ways that I am not aware of.
>
> - Paul
>
> On Dec 18, 2015, at 2:39 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Examples:
>
> >>> l=[1,2,3,4,5]
> >>> l[-1]
> 5
> >>> l[-2]
> 4
> >>> l[2:4]
> [3, 4]
> >>> l[2:]
> [3, 4, 5]
> >>> l[-2:]
> [4, 5]
> >>> l[:3]
> [1, 2, 3]
> >>> l[::2]
> [1, 3, 5]
> >>> l[::]
> [1, 2, 3, 4, 5]
>
>
> Accepting negative indices is problematic for two reasons: it imposes
> runtime overhead in the index operation to check the sign of the index;
> also, it masks fencepost errors, since if you do foo[m-n] and n is
> accidentally greater than m, you'll quietly load the wrong element instead
> of trapping. I'd prefer something like D's `$-n` syntax for explicitly
> annotating end-relative indexes.
>
>
> Yes, we already have facilities to do most of what Python can do here, but
> one major problem IMO is that the “language” of slicing is so non-uniform:
> we have [a.. for this purpose could make it all hang together and also eliminate the
> “why does it have to be so hard to look at the 2nd character of a string?!”
> problem.  That is, use the identifier “$” (yes, that’s an identifier in
> Swift) to denote the beginning-or-end of a collection.  Thus,
>
>   c[c.startIndex.advancedBy(3)] => c[$+3]// Python: c[3]
>   c[c.endIndex.advancedBy(-3)] => c[$-3]// Python: c[-3]
>   c.dropFirst(3)  => c[$+3...] // Python: c[3:]
>   c.dropLast(3) => c[..<$-3] // Python: c[:-3]
>   c.prefix(3) => c[..<$+3] // Python: c[:3]
>   c.suffix(3) =>  c[$-3...] // Python: c[-3:]
>
> It even has the nice connotation that, “this might be a little more expen$ive
> than plain indexing” (which it might, for non-random-access collections).  I
> think the syntax is still a bit heavy, not least because of “..<“ and
> “...”, but the direction has potential.
>
>  I haven’t had the time to really experiment with a design like this; the
> community might be able to help by prototyping and using some
> alternatives.  You can do all of this outside the standard library with
> extensions.
>
> -Dave
>
>
>
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[Dennis Lysenko via swift-evolution]

Genuinely, David, thank you for taking up the mantle of this problem. To
me, the lack of type annotations makes the error handling painful and I
wish the team just hadn't released it until the design was smoothed out
fully. Those dangling catch-all blocks when I've caught all cases make it
uselessly verbose and moreover do not fit with the language at all.

As for the multiple vs. single type annotations, I do think that you need a
concrete example of why this will be different from java to quell the
concerns of all the people that skim the proposal, don't think about it,
and exclaim "but everyone hates it in Java!" so I agree on the singular
type annotations.

Also, your point about being able to mark functions async strongly supports
single type annotations until we get union types (if ever).

I am glad you addressed covariance/contravariance and the semantics of
function types when they throw general errors vs. a specific one.

One question, mainly to the compiler team: would it be reasonable to be
able to use generics covariant over the throws operator? For example, I
could define a function that takes a function which throws E and returns R,
and creates a function that takes a callback which takes an argument of
type Either instead. This would be an incredibly powerful feature.

On Fri, Dec 18, 2015, 8:53 AM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> David,
>
> Thank you for taking the time to continue working on a proposal for typed
> throws.  I agree that this feature is very desirable and appreciate the
> work you’re doing to bring forward a proposal.  I think it’s a great start
> but also has some room for improvement.
>
> First, I think it could be strengthened by incorporating some learning
> from Rust.  My impression is that the Rust community is very happy with
> typed error handling.  Adding some detail about their experience would
> provide a counter-example to those who are concerned about the experience
> in Java and C++.
>
> I agree that error types are an important part of an API contract.  One of
> the big hurdles to doing this well is the need to catch errors when all
> that needs to be done is to wrap and rethrow them.  Ideally should not need
> to do this just to perform a simple type translation to map the underlying
> error into the type we wish to expose as part of a stable API contract.
> You might want to take a look at the From mechanism Rust uses to facilitate
> this.  IMO a proposal for typed error handling should address this issue in
> some way (even if the author determines this mechanism is not necessary or
> a good design cannot be identified).
>
> I would also like to see much more detail on why you think allowing a
> function to throw multiple error types is problematic.  My impression is
> that you have concerns from a usability point of view.  I am on the fence
> here to some degree, but definitely leaning in the direction that allowing
> a function to throw multiple error types is better.
>
> The primary reason I lean this way is that it enables more re-use of
> standard error types.  Custom error types for an API often make sense, but
> not always.  I am concerned about the need to create them just because our
> API contract might reasonably include two or three of the standard error
> types.  Adding new types when they are not necessary introduces complexity
> and cognitive overhead.  It also complicates catching of errors if the new
> custom type is a two or three case enum that just embeds the underlying
> error.
>
> These problems will lead many people to just revert to an untyped throws
> clause.  Objections to typed errors along these lines are common and
> legitimate.  They will arise during review.  It is best if you address them
> in the proposal now in order to focus a review on your solutions.  My
> personal opinion is that allowing multiple error types and including a
> mechanism to perform automatic wrapping when appropriate would go a long
> way towards solving them.
>
> Implementation challenges related to multi-typed errors have been
> discussed on the list quite a bit already.  They would obviously need to be
> addressed if we go in that direction.  I don’t want to downplay those.  But
> I do think we need to try to identify the most usable solution for typed
> errors that we can first and then focus on implementation details.  If the
> design needs to be modified to accommodate implementation at least we will
> have a better idea of what we are giving up.
>
> I am willing to be convinced that a single error type is better than
> multiple error types but the current proposal does not provide a compelling
> argument in that direction.  It just says “Java checked exceptions”.  I
> know these have been pretty much universally considered a serious design
> mistake.  My impression is that there are quite a few reasons for that.  I
> don’t have any direct experience with Java and am not familiar with the
> details.  

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

[Dennis Lysenko via swift-evolution]

Felix,

This seems to be very interestingly tied into your comments about
polymorphism in 'throws' type annotations. Would you not feel that allowing
enums to be built on top of other enums would promote the kind of egregious
proliferation of exception polymorphism that discourages so many from
following Java's checked exception model?

On Fri, Dec 18, 2015 at 11:29 AM Félix Cloutier 
wrote:

> Hi all,
>
> Swift currently has more or less three conceptual types of enums:
> discriminated unions, lists of unique tokens, and lists of value of a raw
> type.
>
> > // Discriminated unions
> > enum Foo {
> >   case Bar(Int)
> >   case Baz(String)
> > }
> >
> > // Lists of unique tokens (mixable with discriminated unions)
> > enum Foo {
> >   case Frob
> >   case Nicate
> > }
> >
> > // Lists of raw values
> > enum Foo: String {
> >   case Bar = "Bar"
> >   case Baz = "Baz"
> > }
>
> I think that the last case could be made more interesting if you could use
> more types as underlying types. For instance, it could probably be extended
> to support another enum as the backing type. One possible use case would be
> to have a big fat enum for all the possible errors that your
> program/library can throw, but refine that list into a shorter enum for
> functions that don't need it all.
>
> > enum MyLibError: ErrorType {
> >   case FileNotFound
> >   case UnexpectedEOF
> >   case PermissionDenied
> >   // ... 300 cases later
> >   case FluxCapacitorFailure
> >   case SplineReticulationError
> > }
> >
> > enum FileSystemError: MyLibError {
> >   case FileNotFound = .FileNotFound
> >   case UnexpectedEOF = .UnexpectedEOF
> >   case PermissionDenied = .PermissionDenied
> > }
>
> This example could be made simpler if the `= .Foo` part was inferred from
> the name, but you get the idea.
>
> In this case, it would be helpful (but not required) that FileSystemError
> was convertible into a MyLibError, so that it could be transparently
> rethrown in a function that uses the larger enum. I personally don't see
> why enums with a specified underlying type can't be implicitly converted to
> it, but this is not currently the case and it probably deserves some
> discussion as well.
>
> Is there any interest in that?
>
> Félix
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[Dennis Lysenko via swift-evolution]

Sorry Matthew, I think my email is having delivery issues because I didn't
see any of those messages when I sent mine, though I see them timestamped
before my message now.

Yes, Felix, those were valid concerns. But, as mentioned before, what we
have now is the most polymorphic thing possible. All those functions throw
ErrorType and that can literally be anything imaginable.

What could solve the issue is if type-annotated throws only allowed final
(closed) classes. Also, if I'm not mistaken, enums are sealed and cannot be
extended so they are a fantastic candidate for avoiding the proliferation
of extending error classes. Maybe it could be limited to enums.



On Fri, Dec 18, 2015, 10:40 AM Matthew Johnson 
wrote:

> On Dec 18, 2015, at 9:25 AM, Dennis Lysenko 
> wrote:
>
> Genuinely, David, thank you for taking up the mantle of this problem. To
> me, the lack of type annotations makes the error handling painful and I
> wish the team just hadn't released it until the design was smoothed out
> fully. Those dangling catch-all blocks when I've caught all cases make it
> uselessly verbose and moreover do not fit with the language at all.
>
> As for the multiple vs. single type annotations, I do think that you need
> a concrete example of why this will be different from java to quell the
> concerns of all the people that skim the proposal, don't think about it,
> and exclaim "but everyone hates it in Java!" so I agree on the singular
> type annotations.
>
> I definitely agree that we need to address the Java problem.  That said, I
> don’t think avoiding knee-jerk objection from people who don’t read and
> consider a proposal carefully is a good way to approach design.  There may
> be good reasons to choose singular type annotations but this is not one of
> them.
>
> I believe Félix raised good points about polymorphism and complex
> hierarchy causing problems in Java.  That sounds like it is the source of
> at least a significant part of the problems with Java’s checked exception
> model.
>
> Also, your point about being able to mark functions async strongly
> supports single type annotations until we get union types (if ever).
>
> I am glad you addressed covariance/contravariance and the semantics of
> function types when they throw general errors vs. a specific one.
>
> One question, mainly to the compiler team: would it be reasonable to be
> able to use generics covariant over the throws operator? For example, I
> could define a function that takes a function which throws E and returns R,
> and creates a function that takes a callback which takes an argument of
> type Either instead. This would be an incredibly powerful feature.
>
> On Fri, Dec 18, 2015, 8:53 AM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> David,
>>
>> Thank you for taking the time to continue working on a proposal for typed
>> throws.  I agree that this feature is very desirable and appreciate the
>> work you’re doing to bring forward a proposal.  I think it’s a great start
>> but also has some room for improvement.
>>
>> First, I think it could be strengthened by incorporating some learning
>> from Rust.  My impression is that the Rust community is very happy with
>> typed error handling.  Adding some detail about their experience would
>> provide a counter-example to those who are concerned about the experience
>> in Java and C++.
>>
>> I agree that error types are an important part of an API contract.  One
>> of the big hurdles to doing this well is the need to catch errors when all
>> that needs to be done is to wrap and rethrow them.  Ideally should not need
>> to do this just to perform a simple type translation to map the underlying
>> error into the type we wish to expose as part of a stable API contract.
>> You might want to take a look at the From mechanism Rust uses to facilitate
>> this.  IMO a proposal for typed error handling should address this issue in
>> some way (even if the author determines this mechanism is not necessary or
>> a good design cannot be identified).
>>
>> I would also like to see much more detail on why you think allowing a
>> function to throw multiple error types is problematic.  My impression is
>> that you have concerns from a usability point of view.  I am on the fence
>> here to some degree, but definitely leaning in the direction that allowing
>> a function to throw multiple error types is better.
>>
>> The primary reason I lean this way is that it enables more re-use of
>> standard error types.  Custom error types for an API often make sense, but
>> not always.  I am concerned about the need to create them just because our
>> API contract might reasonably include two or three of the standard error
>> types.  Adding new types when they are not necessary introduces complexity
>> and cognitive overhead.  It also complicates catching of errors if the new
>> custom type is a two or three case enum that just