Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016 at 7:16 PM, Kevin Ballard wrote: > On Tue, Oct 4, 2016, at 12:01 PM, Xiaodi Wu wrote: > > On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard wrote: > > > On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: > > On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution < > sw

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

Thank you for that! -- E > On Oct 4, 2016, at 4:58 PM, Goffredo Marocchi wrote: > > Here is the message I was talking about: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html > >

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016, at 12:01 PM, Xiaodi Wu wrote: > On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard wrote: >> __ >> On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: >>> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution >>> wrote: __ On Tue, Oct 4, 2016, at 10:44 AM

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

on Mon Oct 03 2016, Kevin Ballard wrote: > On Mon, Oct 3, 2016, at 02:51 PM, Dave Abrahams via swift-evolution wrote: >> >> on Mon Oct 03 2016, Kevin Ballard wrote: >> >> > On Fri, Sep 30, 2016, at 08:53 PM, Dave Abrahams via swift-evolution wrote: >> >> > >> >> on Wed Sep 28 2016, Erica Sad

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

> On 4 Oct 2016, at 19:16, Joe Groff wrote: > >> On Oct 4, 2016, at 11:07 AM, Adrian Zubarev >> wrote: >> >> Doesn’t this imply more performance cost? Don’t get me wrong but the value >> here is not fixed and computed all over again which might waste resources if >> the calculation is compli

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

Here is the message I was talking about: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html Message quoted here for your convenience: > *Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

I noticed this immediately and assumed that it was recognized as suboptimal but tolerable for now. The required underscores were meant to leave space for improvement in this regard, no? If not… sad face. TJ On Tue, Oct 4, 2016 at 12:21 PM, Erica Sadun via swift-evolution < swift-evolution@swift.o

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard wrote: > On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: > > On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: > > > On Oct 4, 2016, a

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

I do not think the boat has sailed. I do remember this issue being actually revisited after initial approval because of the impact it had and quite a few members in this list, myself included, thought it was not helping readability and clarity and that it was strange this came after putting so m

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: > On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution evolut...@swift.org> wrote: >> __ >> >> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: >>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution >>> evolut...@s

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 4, 2016, at 11:47 AM, Joe Groff via swift-evolution > wrote: >> On Oct 4, 2016, at 11:06 AM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: >>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: > > > On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Oct 4, 2016, at 10:28 A

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

It's an interesting idea that needs to be written down in a separate proposal and is tangentially related to the problem we are trying to solve here and now. It is trivial to define this operator and was suggested by Charlie as new API to be added to Optional the last time improving Optionals i

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 4, 2016, at 11:06 AM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: >> >>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Tue, Oct 4, 2016, at 10:28 AM, Nate

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

Okay thanks, I’ll keep that in mind. --  Adrian Zubarev Sent with Airmail Am 4. Oktober 2016 um 20:16:12, Joe Groff (jgr...@apple.com) schrieb: On Oct 4, 2016, at 11:07 AM, Adrian Zubarev wrote: Doesn’t this imply more performance cost? Don’t get me wrong but the value here is not fixed a

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

> On Oct 4, 2016, at 11:07 AM, Adrian Zubarev > wrote: > > Doesn’t this imply more performance cost? Don’t get me wrong but the value > here is not fixed and computed all over again which might waste resources if > the calculation is complicated. Sure we could build some workarounds here and

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: > >> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution >>> evolut...@swift.org>

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

Doesn’t this imply more performance cost? Don’t get me wrong but the value here is not fixed and computed all over again which might waste resources if the calculation is complicated. Sure we could build some workarounds here and there, but the codebase won’t get any prettier after that. Anothe

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

> On Oct 3, 2016, at 12:50 PM, Adrian Zubarev via swift-evolution > wrote: > > Hi there, > > I’m interested if this idea has some potential future in Swift or not. > > Currently RawRepresentable enums accept only a subset of literal types like > String, Character and the Integer family (enum

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Ros

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: ... >>> We had this at one point, but we took it out because people would >>> f

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > wrote: > > On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: >>> >>> ... >>> >> We had this at one point, but we took it out because people would forget to >> test the nil case. I think `?? ""` or `?? nil` really is the best

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

Also IIRC, both of these limitations go away if you conform to RawRepresentable yourself. There is no magic to RawRep. The compiler will just synthesise a failable initialiser and 'rawValue' computed property accessor. Both just simple switch statements matching your provided litera

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

Enum raw types don't have to be strings/integers, but they have to be expressable by string or integer literals. We don't guarantee uniqueness per se, but we do check for duplicate literals and auto-increment integers to fill gaps. So all you have to do is make you

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

> On Oct 4, 2016, at 9:32 AM, Michael Ilseman via swift-evolution > wrote: > >> >> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> SE-0111 established that Swift's type system would not allow function >> argument labels to be ex

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution > wrote: > > SE-0111 established that Swift's type system would not allow function > argument labels to be expressed as part of a function type. As I've been > working with curried functions, I'm discovering an unintended consequen

[swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

SE-0111 established that Swift's type system would not allow function argument labels to be expressed as part of a function type. As I've been working with curried functions, I'm discovering an unintended consequence of this proposal in that it strips curried functions of their external labels a

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

I think I agree with you. The postfix `!` operator is always shorthand for `fatalError()` (and some more syntax), and it would fit nicely with `default: fatalError()`. The Swift usage of `?` is indeed different than `default: break` would do, so `switch?` wouldn’t convey the right message. I ha

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

On Tue, Oct 4, 2016 at 2:07 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > There are still a lot of open questions here to solve. > >- How to statically guarantee the uniqueness + immutability of the >hashValues? > - > > Should we allow only the us

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

There is a plausible argument for `switch!`, because it is not possible for the compiler to prove exhaustiveness in all circumstances where you might know it to be the case. However, I'd be very against `switch?`: it undermines the exhaustiveness guarantee of the switch statement and is wholly inc

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

I would say it's surprising if you don't expect the value to be optional. Swift is such that you can write very long programs without knowing yourself the static type of every variable. It just takes one Optional property of a non-optional struct passed into a string interpolation segment to cau

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On 3 Oct 2016, at 22:41, Kevin Ballard via swift-evolution > wrote: > > On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote: >> Swift developers frequently use string interpolation as a convenient, >> concise syntax for interweaving variable values with strings. The >

[swift-evolution] [Pitch] Can we make `default` on switches optional?

I agree about exhaustiveness checks being very useful. There was a suggestion for `switch?` implicitly adding `default: break`, `switch!` implicitly adding `default: fatalError()`, and `switch` remaining as it is now. I think that’s a great compromise, would you be in favor of that? > -1. The “

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

There are still a lot of open questions here to solve. How to statically guarantee the uniqueness + immutability of the hashValues? Should we allow only the usage of an initializer? Sometimes an init might be not enough and you’d wish you can use custom function which would return the same value