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

[Adrian Zubarev via swift-evolution]

I know that there is this note in Commonly Rejected Changes:

Remove support for default: in switch and just use case _:: default is widely 
used, case _ is too magical, and default is widely precedented in many C family 
languages.
I really like to use the switch instead of if case for pattern matching, just 
because it’s neat block design. I do not want to remove default from switches 
because it’s a must have and powerful feature.

I’d like to know why switches must be exhaustive.

switch someValue {
 
case …:
// Do something
 
case …:
// Do something else

default:  
() // useless nop; do nothing when no pattern matched
}

// VS:

if case … {
 
} else if case … {
 
} else if case … {
 
} // No need for `else`
Can’t we make default optional, or at least on non-enum values?



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

On non-enum values, yes I could support this. However I do not see this as a 
big enough issue.
On enum values? no way….

Btw this would get rid of:

let bytesSend = send(…) // returns an Int

switch bytesSend {
case Int.min ... -1: {…}
case 0: {…}
case 1 ... Int.max: {…} 
default: break // << Imposible
}




> On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I know that there is this note in Commonly Rejected Changes:
> 
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.
> 
> I’d like to know why switches must be exhaustive. 
> 
> switch someValue {
>  
> case …:
> // Do something
>  
> case …:
> // Do something else
> 
> default:  
> () // useless nop; do nothing when no pattern matched
> }
> 
> // VS:
> 
> if case … {
>  
> } else if case … {
>  
> } else if case … {
>  
> } // No need for `else`
> 
> Can’t we make default optional, or at least on non-enum values?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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] [Pitch] Can we make `default` on switches optional?

[Adrian Zubarev via swift-evolution]

This is clearly not a huge issue to solve, but a pitch is a pitch.

From Swift book we know this:

Switch Statements Must Be Exhaustive

In Swift, every possible value of the control expression’s type must match the 
value of at least one pattern of a case. When this simply isn’t feasible (for 
instance, when the control expression’s type is Int), you can include a default 
case to satisfy the requirement.
Even for enum values an optional default would mean that you don’t care about 
the other cases in your current switch, which basically again would be another 
useless nop.

enum A {
case a, b, c
}

var value = A.a

switch value {
 
case .a:
value = A.b
 
default:
() // I don't care
}

// Do something else  

switch value {
 
case .b:
value = A.c
 
default:
() // I don't care
}
Sure the error message is there to notify you that you might forget to handle 
some case, but how we handle that specific case is still up to us.

I’d really like to know what could be dangerous here when default would be 
optional.

I can’t tell if this would have some impact on the ABI or not. I’d say it’s 
additive because it doesn’t break any existing code but removes an existing 
restriction.

The next thought might be an overkill (or maybe not):

How about making default optional everywhere + introducing a new attribute that 
allows the optional default on that particular enum, but by default every 
current existing enum should be handled exhaustively.

Bikeshedding:

enum A {
case a, b, c
}

var value = A.a

switch value {
 
case .a:
value = A.b
 
} // Error: switch must be exhaustive, consider adding a default clause

// VS:

@discardableCase enum B {
case d, e, f
}

let anotherValue = B.d

switch anotherValue {
 
case .d:
// Do something
 
case .e:
// Do something else
 
} // Just fine; We don't care here about `.f`


-- 
Adrian Zubarev
Sent with Airmail

Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:

On non-enum values, yes I could support this. However I do not see this as a 
big enough issue.  
On enum values? no way….  

Btw this would get rid of:  

let bytesSend = send(…) // returns an Int  

switch bytesSend {  
case Int.min ... -1: {…}  
case 0: {…}  
case 1 ... Int.max: {…}  
default: break // << Imposible  
}  




> On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution 
>  wrote:  
>  
> I know that there is this note in Commonly Rejected Changes:  
>  
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.  
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.  
>  
> I’d like to know why switches must be exhaustive.  
>  
> switch someValue {  
>  
> case …:  
> // Do something  
>  
> case …:  
> // Do something else  
>  
> default:  
> () // useless nop; do nothing when no pattern matched  
> }  
>  
> // VS:  
>  
> if case … {  
>  
> } else if case … {  
>  
> } else if case … {  
>  
> } // No need for `else`  
>  
> Can’t we make default optional, or at least on non-enum values?  
>  
>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> ___  
> 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] [Pitch] Can we make `default` on switches optional?

[Ross O'Brien via swift-evolution]

There has been a little discussion on this before, and I think there's a
need for something along these lines - I've written code where I've used
'guard' to ensure that an Int was within a certain range, and then
performed a switch on the Int, requiring an ugly-looking 'default:
fatalError()' at the end to dismiss the warning.

But exhaustive switches are also useful.

There was an elegant suggestion that we apply '?' and '!' to the switch
keyword. Basically:
- 'switch ' is exhaustive across values and enum states and the
compiler will warn you if you omit an enum state or default case.
- 'switch? ' is not exhaustive but the compiler should still
check the flow (to ensure all paths return values, that kind of thing).
- 'switch! ' is not exhaustive but it assumes one of the cases
will match, and crashes otherwise.

Basically, switch wouldn't change, but appending the '?' is equivalent to
typing 'default: break' as your final case, and appending '!' is equivalent
to typing 'default: fatalError()' as your final case. The meanings are
roughly analogous to their meanings for Optionals, so hopefully there
wouldn't be much confusion.


On Mon, Oct 3, 2016 at 11:55 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> This is clearly not a huge issue to solve, but a pitch is a pitch.
>
> From Swift book we know this:
>
> *Switch Statements Must Be Exhaustive*
>
> In Swift, every possible value of the control expression’s type must match
> the value of at least one pattern of a case. When this simply isn’t
> feasible (for instance, when the control expression’s type is Int), you can
> include a default case to satisfy the requirement.
>
> Even for enum values an optional default would mean that you don’t care
> about the other cases in your current switch, which basically again would
> be another useless nop.
>
> enum A {
> case a, b, c
> }
>
> var value = A.a
>
> switch value {
>
> case .a:
> value = A.b
>
> default:
> () // I don't care
> }
>
> // Do something else
>
> switch value {
>
> case .b:
> value = A.c
>
> default:
> () // I don't care
> }
>
> Sure the error message is there to notify you that you might forget to
> handle some case, but how we handle that specific case is still up to us.
>
> I’d really like to know what could be dangerous here when default would
> be optional.
>
> I can’t tell if this would have some impact on the ABI or not. I’d say
> it’s additive because it doesn’t break any existing code but removes an
> existing restriction.
> --
>
> The next thought might be an overkill (or maybe not):
>
> How about making default optional everywhere + introducing a new
> attribute that allows the optional default on that particular enum, but
> by default every current existing enum should be handled exhaustively.
>
> Bikeshedding:
>
> enum A {
> case a, b, c
> }
>
> var value = A.a
>
> switch value {
>
> case .a:
> value = A.b
>
> } // Error: switch must be exhaustive, consider adding a default clause
>
> // VS:
>
> @discardableCase enum B {
> case d, e, f
> }
>
> let anotherValue = B.d
>
> switch anotherValue {
>
> case .d:
> // Do something
>
> case .e:
> // Do something else
>
> } // Just fine; We don't care here about `.f`
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:
>
> On non-enum values, yes I could support this. However I do not see this as
> a big enough issue.
> On enum values? no way….
>
> Btw this would get rid of:
>
> let bytesSend = send(…) // returns an Int
>
> switch bytesSend {
> case Int.min ... -1: {…}
> case 0: {…}
> case 1 ... Int.max: {…}
> default: break // << Imposible
> }
>
>
>
>
> > On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I know that there is this note in Commonly Rejected Changes:
> >
> > Remove support for default: in switch and just use case _:: default is
> widely used, case _ is too magical, and default is widely precedented in
> many C family languages.
> > I really like to use the switch instead of if case for pattern matching,
> just because it’s neat block design. I do not want to remove default from
> switches because it’s a must have and powerful feature.
> >
> > I’d like to know why switches must be exhaustive.
> >
> > switch someValue {
> >
> > case …:
> > // Do something
> >
> > case …:
> > // Do something else
> >
> > default:
> > () // useless nop; do nothing when no pattern matched
> > }
> >
> > // VS:
> >
> > if case … {
> >
> > } else if case … {
> >
> > } else if case … {
> >
> > } // No need for `else`
> >
> > Can’t we make default optional, or at least on non-enum values?
> >
> >
> >
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

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

[Rien via swift-evolution]

In my code, I ‘use’ the forced coverage of the case’s to be reminded of area’s 
where I have to update my code when the enum’s change.
I.e. choosing for an enum solution is partly motivated by the factor that 
case-coverage has to be complete.
I’d hate to miss that.

Rien.

> On 03 Oct 2016, at 12:55, Adrian Zubarev  
> wrote:
> 
> This is clearly not a huge issue to solve, but a pitch is a pitch.
> 
> From Swift book we know this:
> 
> Switch Statements Must Be Exhaustive
> 
> In Swift, every possible value of the control expression’s type must match 
> the value of at least one pattern of a case. When this simply isn’t feasible 
> (for instance, when the control expression’s type is Int), you can include a 
> default case to satisfy the requirement.
> Even for enum values an optional default would mean that you don’t care about 
> the other cases in your current switch, which basically again would be 
> another useless nop.
> 
> enum A {
> case a, b, c
> }
> 
> var value = A.a
> 
> switch value {
>  
> case .a:
> value = A.b
>  
> default:
> () // I don't care
> }
> 
> // Do something else  
> 
> switch value {
>  
> case .b:
> value = A.c
>  
> default:
> () // I don't care
> }
> 
> Sure the error message is there to notify you that you might forget to handle 
> some case, but how we handle that specific case is still up to us.
> 
> I’d really like to know what could be dangerous here when default would be 
> optional.
> 
> I can’t tell if this would have some impact on the ABI or not. I’d say it’s 
> additive because it doesn’t break any existing code but removes an existing 
> restriction. 
> 
> The next thought might be an overkill (or maybe not):
> 
> How about making default optional everywhere + introducing a new attribute 
> that allows the optional default on that particular enum, but by default 
> every current existing enum should be handled exhaustively.
> 
> Bikeshedding:
> 
> enum A {
> case a, b, c
> }
> 
> var value = A.a
> 
> switch value {
>  
> case .a:
> value = A.b
>  
> } // Error: switch must be exhaustive, consider adding a default clause
> 
> // VS:
> 
> @discardableCase enum B {
> case d, e, f
> }
> 
> let anotherValue = B.d
> 
> switch anotherValue {
>  
> case .d:
> // Do something
>  
> case .e:
> // Do something else
>  
> } // Just fine; We don't care here about `.f`
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:
> 
>> On non-enum values, yes I could support this. However I do not see this as a 
>> big enough issue. 
>> On enum values? no way…. 
>> 
>> Btw this would get rid of: 
>> 
>> let bytesSend = send(…) // returns an Int 
>> 
>> switch bytesSend { 
>> case Int.min ... -1: {…} 
>> case 0: {…} 
>> case 1 ... Int.max: {…}  
>> default: break // << Imposible 
>> } 
>> 
>> 
>> 
>> 
>> > On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution 
>> >  wrote: 
>> >  
>> > I know that there is this note in Commonly Rejected Changes: 
>> >  
>> > Remove support for default: in switch and just use case _:: default is 
>> > widely used, case _ is too magical, and default is widely precedented in 
>> > many C family languages. 
>> > I really like to use the switch instead of if case for pattern matching, 
>> > just because it’s neat block design. I do not want to remove default from 
>> > switches because it’s a must have and powerful feature. 
>> >  
>> > I’d like to know why switches must be exhaustive.  
>> >  
>> > switch someValue { 
>> >  
>> > case …: 
>> > // Do something 
>> >  
>> > case …: 
>> > // Do something else 
>> >  
>> > default:  
>> > () // useless nop; do nothing when no pattern matched 
>> > } 
>> >  
>> > // VS: 
>> >  
>> > if case … { 
>> >  
>> > } else if case … { 
>> >  
>> > } else if case … { 
>> >  
>> > } // No need for `else` 
>> >  
>> > Can’t we make default optional, or at least on non-enum values? 
>> >  
>> >  
>> >  
>> >  
>> > --  
>> > Adrian Zubarev 
>> > Sent with Airmail 
>> >  
>> > ___ 
>> > 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] [Pitch] Can we make `default` on switches optional?

[Adrian Zubarev via swift-evolution]

I’m not sure about the design itself, but the idea is great. I couldn’t even 
foresee that there might be a need for switch!. This is definitely better than 
my suggestion of a new attribute. I most cases I’d need switch? to replace the 
ugly-looking if case … { … } else if case … { … }.

Was there a rejected proposal on this that I missed?



-- 
Adrian Zubarev
Sent with Airmail

Am 3. Oktober 2016 um 13:16:54, Ross O'Brien (narrativium+sw...@gmail.com) 
schrieb:

There has been a little discussion on this before, and I think there's a need 
for something along these lines - I've written code where I've used 'guard' to 
ensure that an Int was within a certain range, and then performed a switch on 
the Int, requiring an ugly-looking 'default: fatalError()' at the end to 
dismiss the warning.

But exhaustive switches are also useful.

There was an elegant suggestion that we apply '?' and '!' to the switch 
keyword. Basically:
- 'switch ' is exhaustive across values and enum states and the 
compiler will warn you if you omit an enum state or default case.
- 'switch? ' is not exhaustive but the compiler should still check 
the flow (to ensure all paths return values, that kind of thing).
- 'switch! ' is not exhaustive but it assumes one of the cases will 
match, and crashes otherwise.

Basically, switch wouldn't change, but appending the '?' is equivalent to 
typing 'default: break' as your final case, and appending '!' is equivalent to 
typing 'default: fatalError()' as your final case. The meanings are roughly 
analogous to their meanings for Optionals, so hopefully there wouldn't be much 
confusion.


On Mon, Oct 3, 2016 at 11:55 AM, Adrian Zubarev via swift-evolution 
 wrote:
This is clearly not a huge issue to solve, but a pitch is a pitch.

From Swift book we know this:

Switch Statements Must Be Exhaustive

In Swift, every possible value of the control expression’s type must match the 
value of at least one pattern of a case. When this simply isn’t feasible (for 
instance, when the control expression’s type is Int), you can include a default 
case to satisfy the requirement.
Even for enum values an optional default would mean that you don’t care about 
the other cases in your current switch, which basically again would be another 
useless nop.

enum A {
case a, b, c
}

var value = A.a

switch value {
  
case .a:
value = A.b
  
default:
() // I don't care
}

// Do something else   

switch value {
  
case .b:
value = A.c
  
default:
() // I don't care
}
Sure the error message is there to notify you that you might forget to handle 
some case, but how we handle that specific case is still up to us.

I’d really like to know what could be dangerous here when default would be 
optional.

I can’t tell if this would have some impact on the ABI or not. I’d say it’s 
additive because it doesn’t break any existing code but removes an existing 
restriction.

The next thought might be an overkill (or maybe not):

How about making default optional everywhere + introducing a new attribute that 
allows the optional default on that particular enum, but by default every 
current existing enum should be handled exhaustively.

Bikeshedding:

enum A {
case a, b, c
}

var value = A.a

switch value {
  
case .a:
value = A.b
  
} // Error: switch must be exhaustive, consider adding a default clause

// VS:

@discardableCase enum B {
case d, e, f
}

let anotherValue = B.d

switch anotherValue {
  
case .d:
// Do something
  
case .e:
// Do something else
  
} // Just fine; We don't care here about `.f`


-- 
Adrian Zubarev
Sent with Airmail

Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:

On non-enum values, yes I could support this. However I do not see this as a 
big enough issue.
On enum values? no way….

Btw this would get rid of:

let bytesSend = send(…) // returns an Int

switch bytesSend {
case Int.min ... -1: {…}
case 0: {…}
case 1 ... Int.max: {…}
default: break // << Imposible
}




> On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution 
>  wrote:
>
> I know that there is this note in Commonly Rejected Changes:
>
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.
>
> I’d like to know why switches must be exhaustive.
>
> switch someValue {
>
> case …:
> // Do something
>
> case …:
> // Do something else
>
> default:
> () // useless nop; do nothing when no pattern matched
> }
>
> // VS:
>
> if case … {
>
> } else if case … {
>
> } else if case … {
>
> } // No need for `else`
>
> Can’t we make default optional, or at least on non-enum values?
>
>
>
>
> --
> Adrian Zubarev
> Se

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

[Jeremy Pereira via swift-evolution]

> On 3 Oct 2016, at 11:14, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I know that there is this note in Commonly Rejected Changes:
> 
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.
> 
> I’d like to know why switches must be exhaustive. 
> 
> switch someValue {
>  
> case …:
> // Do something
>  
> case …:
> // Do something else
> 
> default:  
> () // useless nop; do nothing when no pattern matched
> }
> 
> // VS:
> 
> if case … {
>  
> } else if case … {
>  
> } else if case … {
>  
> } // No need for `else`
> 
> Can’t we make default optional, or at least on non-enum values?
> 
> 

I absolutely cannot see why 

default: break

doesn’t already do this for you. It’s not a useless no-op, it signifies to the 
compiler that you really do want to ignore the other cases and it’s not a 
mistake.

I think there is a case for allowing default: break to be at the top of the 
switch but other than that, I like the fact that not having a an explicitly 
exhaustive switch generates an error.


> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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] [Pitch] Can we make `default` on switches optional?

[Rien via swift-evolution]

> On 03 Oct 2016, at 13:16, Ross O'Brien  wrote:
> 
> There has been a little discussion on this before, and I think there's a need 
> for something along these lines - I've written code where I've used 'guard' 
> to ensure that an Int was within a certain range, and then performed a switch 
> on the Int, requiring an ugly-looking 'default: fatalError()' at the end to 
> dismiss the warning.
> 
> But exhaustive switches are also useful.
> 
> There was an elegant suggestion that we apply '?' and '!' to the switch 
> keyword. Basically:
> - 'switch ' is exhaustive across values and enum states and the 
> compiler will warn you if you omit an enum state or default case.
> - 'switch? ' is not exhaustive but the compiler should still 
> check the flow (to ensure all paths return values, that kind of thing).

Swift: The questionable language… lol

> - 'switch! ' is not exhaustive but it assumes one of the cases 
> will match, and crashes otherwise.
> 
> Basically, switch wouldn't change, but appending the '?' is equivalent to 
> typing 'default: break' as your final case, and appending '!' is equivalent 
> to typing 'default: fatalError()' as your final case. The meanings are 
> roughly analogous to their meanings for Optionals, so hopefully there 
> wouldn't be much confusion.
> 

Though I am not 100% on the “feel” of this, it would work imo.

Rien.

> 
> On Mon, Oct 3, 2016 at 11:55 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> This is clearly not a huge issue to solve, but a pitch is a pitch.
> 
> From Swift book we know this:
> 
> Switch Statements Must Be Exhaustive
> 
> In Swift, every possible value of the control expression’s type must match 
> the value of at least one pattern of a case. When this simply isn’t feasible 
> (for instance, when the control expression’s type is Int), you can include a 
> default case to satisfy the requirement.
> 
> Even for enum values an optional default would mean that you don’t care about 
> the other cases in your current switch, which basically again would be 
> another useless nop.
> 
> enum A {
> case a, b, c
> }
> 
> var value = A.a
> 
> switch value {
>  
> case .a:
> value = A.b
>  
> default:
> () // I don't care
> }
> 
> // Do something else  
> 
> switch value {
>  
> case .b:
> value = A.c
>  
> default:
> () // I don't care
> }
> 
> Sure the error message is there to notify you that you might forget to handle 
> some case, but how we handle that specific case is still up to us.
> 
> I’d really like to know what could be dangerous here when default would be 
> optional.
> 
> I can’t tell if this would have some impact on the ABI or not. I’d say it’s 
> additive because it doesn’t break any existing code but removes an existing 
> restriction.
> 
> The next thought might be an overkill (or maybe not):
> 
> How about making default optional everywhere + introducing a new attribute 
> that allows the optional default on that particular enum, but by default 
> every current existing enum should be handled exhaustively.
> 
> Bikeshedding:
> 
> enum A {
> case a, b, c
> }
> 
> var value = A.a
> 
> switch value {
>  
> case .a:
> value = A.b
>  
> } // Error: switch must be exhaustive, consider adding a default clause
> 
> // VS:
> 
> @discardableCase enum B {
> case d, e, f
> }
> 
> let anotherValue = B.d
> 
> switch anotherValue {
>  
> case .d:
> // Do something
>  
> case .e:
> // Do something else
>  
> } // Just fine; We don't care here about `.f`
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:
> 
>> On non-enum values, yes I could support this. However I do not see this as a 
>> big enough issue. 
>> On enum values? no way…. 
>> 
>> Btw this would get rid of: 
>> 
>> let bytesSend = send(…) // returns an Int 
>> 
>> switch bytesSend { 
>> case Int.min ... -1: {…} 
>> case 0: {…} 
>> case 1 ... Int.max: {…} 
>> default: break // << Imposible 
>> } 
>> 
>> 
>> 
>> 
>> > On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution 
>> >  wrote: 
>> > 
>> > I know that there is this note in Commonly Rejected Changes: 
>> > 
>> > Remove support for default: in switch and just use case _:: default is 
>> > widely used, case _ is too magical, and default is widely precedented in 
>> > many C family languages. 
>> > I really like to use the switch instead of if case for pattern matching, 
>> > just because it’s neat block design. I do not want to remove default from 
>> > switches because it’s a must have and powerful feature. 
>> > 
>> > I’d like to know why switches must be exhaustive. 
>> > 
>> > switch someValue { 
>> > 
>> > case …: 
>> > // Do something 
>> > 
>> > case …: 
>> > // Do something else 
>> > 
>> > default: 
>> > () // useless nop; do nothing when no pattern matched 
>> > } 
>> > 
>> > // VS: 
>> > 
>> > if case … { 
>> > 
>> > } else if case … { 
>> > 
>> > } else if case … { 

Re: [swift-evolution] [Pre-proposal] Enforcing Correct use of Array Indices

[Haravikk via swift-evolution]

> On 30 Sep 2016, at 13:10, Dave Abrahams via swift-evolution 
>  wrote:
> on Thu Sep 29 2016, Haravikk  > wrote:
>> So the issue of Array index safety came up on the discussion for the
>> .indexed() proposal. Now of course there's nothing wrong with arrays
>> using integers as indices as such, but it does mean that indices can
>> be manipulated outside of the array, which somewhat defeats the idea
>> of the indexing model requiring them to be passed back to the parent
>> collection for manipulation.
>> 
>> In a few types of my own I've avoided this problem by doing the
>> following:
>> 
>> public struct MyMaskedIndex : Comparable { fileprivate var raw:Int }
>> // Comparable conformance omitted
>> 
>> public struct MyType : Collection {
>>// Lots of stuff omitted
>>public func distance(from start:MyMaskedIndex, to
>> end:MyMaskedIndex) -> Int {
>>return end.raw - start.raw;
>>}
>> }
>> 
>> In essence MaskedIndex is still just an Int, and should optimise as
>> such, but in development the use of a type like this ensures that
>> indices from my collection can't be manipulated externally, which
>> enables the type-checker to conveniently prevent any mistakes I might
>> make. It's a handy pattern for other things like hashed values,
>> ensuring I can't use unhashed values of the same type by accident and
>> so-on.
> 
> Yeah, but it doesn't really ensure you won't use an invalid index.
> Among many other things, you can always reset the collection to an empty
> state and all the old indices become invalid with respect to it.
> 
>> I just wanted to raise the topic to see what other people thought
>> about the idea of doing something similar for Array and any other
>> types that use integer types directly as indices? For convenience it
>> is still possible to have a public initialiser on the masking type(s),
>> so that custom values can be used, but by using MaskedIndex(raw:) it
>> should be much more obvious what's happening.
> 
> Believe me, we considered this when doing the Array design.  Being able
> to index an Array with Ints is pretty fundamental to its usability and
> adoptability, and wrapping the index doesn't buy any real safety.

It certainly doesn't solve all the problems, but then it really is just 
intended to avoid the simple mistake of manipulating the index externally; like 
I say, the wrapped value should optimise away (since all it is is an Int in 
reality), and if it's given a public constructor then a person can still do 
external manipulation if they must, they just have to be explicit about it.

The idea is literally just to let the type-checker catch some simple, but easy 
to make, errors that purpose-made index types like DictionaryIndex aren't 
vulnerable to.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-proposal] Enforcing Correct use of Array Indices

[Dave Abrahams via swift-evolution]

on Mon Oct 03 2016, Haravikk  wrote:

>> On 30 Sep 2016, at 13:10, Dave Abrahams via swift-evolution
>>  wrote:
>> on Thu Sep 29 2016, Haravikk
>> > >
>
>> wrote:
>>> So the issue of Array index safety came up on the discussion for the
>>> .indexed() proposal. Now of course there's nothing wrong with arrays
>>> using integers as indices as such, but it does mean that indices can
>>> be manipulated outside of the array, which somewhat defeats the idea
>>> of the indexing model requiring them to be passed back to the parent
>>> collection for manipulation.
>>> 
>>> In a few types of my own I've avoided this problem by doing the
>>> following:
>>> 
>>> public struct MyMaskedIndex : Comparable { fileprivate var raw:Int }
>>> // Comparable conformance omitted
>>> 
>>> public struct MyType : Collection {
>>>// Lots of stuff omitted
>>>public func distance(from start:MyMaskedIndex, to
>>> end:MyMaskedIndex) -> Int {
>>>return end.raw - start.raw;
>>>}
>>> }
>>> 
>>> In essence MaskedIndex is still just an Int, and should optimise as
>>> such, but in development the use of a type like this ensures that
>>> indices from my collection can't be manipulated externally, which
>>> enables the type-checker to conveniently prevent any mistakes I might
>>> make. It's a handy pattern for other things like hashed values,
>>> ensuring I can't use unhashed values of the same type by accident and
>>> so-on.
>> 
>> Yeah, but it doesn't really ensure you won't use an invalid index.
>> Among many other things, you can always reset the collection to an empty
>> state and all the old indices become invalid with respect to it.
>> 
>>> I just wanted to raise the topic to see what other people thought
>>> about the idea of doing something similar for Array and any other
>>> types that use integer types directly as indices? For convenience it
>>> is still possible to have a public initialiser on the masking type(s),
>>> so that custom values can be used, but by using MaskedIndex(raw:) it
>>> should be much more obvious what's happening.
>> 
>> Believe me, we considered this when doing the Array design.  Being able
>> to index an Array with Ints is pretty fundamental to its usability and
>> adoptability, and wrapping the index doesn't buy any real safety.
>
> It certainly doesn't solve all the problems, but then it really is
> just intended to avoid the simple mistake of manipulating the index
> externally; like I say, the wrapped value should optimise away (since
> all it is is an Int in reality), and if it's given a public
> constructor then a person can still do external manipulation if they
> must, they just have to be explicit about it.
>
> The idea is literally just to let the type-checker catch some simple,
> but easy to make, errors that purpose-made index types like
> DictionaryIndex aren't vulnerable to.

Yes, I understand.  You asked what “people thought;” I was saying we
thought about it and explaining the rationale for our choice.  The
benefits don't seem to outweigh the costs.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

[Joe Groff via swift-evolution]

> On Sep 30, 2016, at 10:48 PM, Russ Bishop  wrote:
> 
> 
>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution 
>>  wrote:
>>> 
>> 
>> 
>> Personally, I consider the first one to be a fairly-low-risk extension to 
>> SE-0139 that’s borderline bug-fix. We already know that those types have 
>> weak numeric representations in Objective-C because they come from 
>> Objective-C, so losing some of the type info by bridging to Objective-C is 
>> (IMO) falls out of having strong types in Swift for weaker types in 
>> Objective-C.
>> 
>> The second one makes me a little nervous, I think because it weakens typing 
>> for types defined in Swift. These types don’t naturally have Objective-C 
>> counterparts, so if we’re going to weaken the types, it feels like we should 
>> only do so via some explicit conformance (e.g., to a publicly-available form 
>> of _ObjectiveCBridgeable).
>> 
>>  - Doug
>> 
> 
> I’m up for reviving the ObjectiveCBridgeable proposal :)

I kind of hope id-as-Any leads us in a direction where ObjectiveCBridgeable 
isn't necessary to expose for most user types. If we at some point allow Swift 
value types to conform to ObjC protocols, expose @objc methods, and opt in to 
being representable in ObjC as classes, then most of the work of building an 
ObjC class to bridge to could potentially be handled by the compiler.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

-1 in general.  I want smarter exhaustiveness analysis, but I don’t want to be 
able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
they’re clearly in the domain of possible values that can be fed to a 
switch-case.  Exhaustiveness guarantees wellformedness of a program that does 
happen to go wrong, and makes it much easier to verify the correctness of the 
flow of control of the containing block because all points from the switch must 
be covered.  We also don’t have the type-level tools to convince the checker to 
allow you to remove unreachable cases.  If it’s really a problem that you are 
writing default cases everywhere, just bailout in a fatal error with a nice 
description.  It never hurts.

~Robert Widmann

> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I know that there is this note in Commonly Rejected Changes 
> :
> 
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.
> 
> I’d like to know why switches must be exhaustive. 
> 
> switch someValue {
>  
> case …:
> // Do something
>  
> case …:
> // Do something else
> 
> default:  
> () // useless nop; do nothing when no pattern matched
> }
> 
> // VS:
> 
> if case … {
>  
> } else if case … {
>  
> } else if case … {
>  
> } // No need for `else`
> Can’t we make default optional, or at least on non-enum values?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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 draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

On Fri, Sep 30, 2016, at 08:53 PM, Dave Abrahams via swift-evolution wrote:
> 
> on Wed Sep 28 2016, Erica Sadun  wrote:
> 
> > Indices have a specific, fixed meaning in Swift, which are used to create 
> > valid collection
> > subscripts. This proposal introduces indexed() to produce a more 
> > semantically relevant sequence by
> > pairing a collection's indices with its members. While it is trivial to 
> > create a solution in Swift,
> > the most common developer approach shown here calculates indexes twice:
> >
> > extension Collection {
> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> > /// consecutive collection index, and *x* represents an element of
> > /// the sequence.
> > func indexed() -> Zip2Sequence {
> > return zip(indices, self)
> > }
> > }
> 
> How does this calculate indices twice?

It calculates indices twice for any collection that uses IndexingIterator as 
its iterator. And for collections that doesn't, it still does the moral 
equivalent, because it's calculating an index offset along with whatever work 
the Iterator does to calculate the next element.

As an example, if my collection is `someArray.lazy.filter(…)` then 
zip(col.indices, col) will run the filter twice over the collection.

> > Incrementing an index in some collections can be unnecessarily
> > costly. 
> 
> Seems like it's only *unnecessarily* costly in badly implemented
> collections?

A collection doesn't have to be badly-implemented to have a non-trivial cost 
for calculating the next element. As above, someArray.lazy.filter(…) is a good 
example of such a collection.

> > In a lazy filtered collection, an index increment is potentially
> > O(N). We feel this is better addressed introducing a new function into
> > the Standard Library to provide a more efficient design that avoids
> > the attractive nuisance of the "obvious" solution.
> 
> I am generally opposed to adding this.  The usual solution developers
> will reach for here is:
> 
> for i in x.indices {
> somethingWith(x[i])
> }
> 
> zip(indices, self) is only suboptimal for lazy filtered sequences, which
> should be used with care anyhow (see the note here:
> http://swiftdoc.org/v3.0/type/LazyFilterCollection/).

It's suboptimal for any collection with a non-trivial index.

> If you really need a lazy sequence of pairs that's optimal with lazy
> filtered sequences, 
> 
> x.indices.lazy.map { ($0, x[$0]) }
> 
> is a good solution and pretty easy to write.

And yet people will write zip(x.indices, x) instead because it's shorter and 
not immediately obvious that it may be suboptimal depending on the collection.

Why are you opposed to adding this? The ability to work around its lack doesn't 
mean it doesn't have value, and the fact that the simplest workaround is not 
the best one is I think a good reason to make the easiest solution into the 
best one (by providing .indexed()). Add to that the fact that a lot of people 
probably use .enumerated() to produce indexes when working with arrays, and 
this is a pitfall when working with other types, such as ArraySlice which still 
has Int indexes but is no longer zero-based.

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

-1 from me as well. This suggestion falls into the same category as those
about making `else` optional after `guard`, which is repeatedly rejected.
Since code is read more often than written, explicit handling of the
default case never hurts and can increase clarity. Not having to write
`default: break` offers no help in writing correct code and IMO can't
justify new syntax or the changing of a well-known control statement.

On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want
> to be able to ignore cases that “can’t happen” (so say we, writer of bugs)
> when they’re clearly in the domain of possible values that can be fed to a
> switch-case.  Exhaustiveness guarantees wellformedness of a program that
> does happen to go wrong, and makes it much easier to verify the correctness
> of the flow of control of the containing block because all points from the
> switch must be covered.  We also don’t have the type-level tools to
> convince the checker to allow you to remove unreachable cases.  If it’s
> really a problem that you are writing default cases everywhere, just
> bailout in a fatal error with a nice description.  It never hurts.
>
> ~Robert Widmann
>
> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I know that there is this note in Commonly Rejected Changes
> 
> :
>
> Remove support for default: in switch and just use case _:: default is
> widely used, case _ is too magical, and default is widely precedented in
> many C family languages.
>
> I really like to use the switch instead of if case for pattern matching,
> just because it’s neat block design. I do not want to remove default from
> switches because it’s a must have and powerful feature.
>
> I’d like to know why switches must be exhaustive.
>
> switch someValue {
>
> case …:
> // Do something
>
> case …:
> // Do something else
>
> default:
> () // useless nop; do nothing when no pattern matched
> }
>
> // VS:
>
> if case … {
>
> } else if case … {
>
> } else if case … {
>
> } // No need for `else`
>
> Can’t we make default optional, or at least on non-enum values?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> ___
> 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] [Pitch] Can we make `default` on switches optional?

[Matthew Johnson via swift-evolution]

I agree with previous commenters.  I very much support improved exhaustiveness 
analysis reducing the circumstances where a default clause is necessary.  But I 
think requiring it unless the compiler can *prove* you have covered every 
possibility communicates important information that facilitates reasoning to 
readers / maintainers of the code.


> On Oct 3, 2016, at 12:41 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> -1 from me as well. This suggestion falls into the same category as those 
> about making `else` optional after `guard`, which is repeatedly rejected. 
> Since code is read more often than written, explicit handling of the default 
> case never hurts and can increase clarity. Not having to write `default: 
> break` offers no help in writing correct code and IMO can't justify new 
> syntax or the changing of a well-known control statement.
> 
> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
> they’re clearly in the domain of possible values that can be fed to a 
> switch-case.  Exhaustiveness guarantees wellformedness of a program that does 
> happen to go wrong, and makes it much easier to verify the correctness of the 
> flow of control of the containing block because all points from the switch 
> must be covered.  We also don’t have the type-level tools to convince the 
> checker to allow you to remove unreachable cases.  If it’s really a problem 
> that you are writing default cases everywhere, just bailout in a fatal error 
> with a nice description.  It never hurts.
> 
> ~Robert Widmann
> 
>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I know that there is this note in Commonly Rejected Changes 
>> :
>> 
>> Remove support for default: in switch and just use case _:: default is 
>> widely used, case _ is too magical, and default is widely precedented in 
>> many C family languages.
>> I really like to use the switch instead of if case for pattern matching, 
>> just because it’s neat block design. I do not want to remove default from 
>> switches because it’s a must have and powerful feature.
>> 
>> I’d like to know why switches must be exhaustive. 
>> 
>> switch someValue {
>>  
>> case …:
>> // Do something
>>  
>> case …:
>> // Do something else
>> 
>> default:  
>> () // useless nop; do nothing when no pattern matched
>> }
>> 
>> // VS:
>> 
>> if case … {
>>  
>> } else if case … {
>>  
>> } else if case … {
>>  
>> } // No need for `else`
>> Can’t we make default optional, or at least on non-enum values?
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> ___
>> 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] [Pitch] Can we make `default` on switches optional?

[João Pinheiro via swift-evolution]

-1 from me too.

Avoiding having to write "default: break" isn't a good justification to 
introduce new syntax. It would make the understanding of case switches harder 
without providing any real benefit for the syntax bloat.

João Pinheiro


> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> -1 from me as well. This suggestion falls into the same category as those 
> about making `else` optional after `guard`, which is repeatedly rejected. 
> Since code is read more often than written, explicit handling of the default 
> case never hurts and can increase clarity. Not having to write `default: 
> break` offers no help in writing correct code and IMO can't justify new 
> syntax or the changing of a well-known control statement.
> 
> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
> they’re clearly in the domain of possible values that can be fed to a 
> switch-case.  Exhaustiveness guarantees wellformedness of a program that does 
> happen to go wrong, and makes it much easier to verify the correctness of the 
> flow of control of the containing block because all points from the switch 
> must be covered.  We also don’t have the type-level tools to convince the 
> checker to allow you to remove unreachable cases.  If it’s really a problem 
> that you are writing default cases everywhere, just bailout in a fatal error 
> with a nice description.  It never hurts.
> 
> ~Robert Widmann
> 
>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I know that there is this note in Commonly Rejected Changes 
>> :
>> 
>> Remove support for default: in switch and just use case _:: default is 
>> widely used, case _ is too magical, and default is widely precedented in 
>> many C family languages.
>> I really like to use the switch instead of if case for pattern matching, 
>> just because it’s neat block design. I do not want to remove default from 
>> switches because it’s a must have and powerful feature.
>> 
>> I’d like to know why switches must be exhaustive. 
>> 
>> switch someValue {
>>  
>> case …:
>> // Do something
>>  
>> case …:
>> // Do something else
>> 
>> default:  
>> () // useless nop; do nothing when no pattern matched
>> }
>> 
>> // VS:
>> 
>> if case … {
>>  
>> } else if case … {
>>  
>> } else if case … {
>>  
>> } // No need for `else`
>> Can’t we make default optional, or at least on non-enum values?
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> ___
>> 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

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

[Harlan Haskins via swift-evolution]

Hey all,

Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
mitigate something that's burned us all since Swift 1. We'd love some feedback!

It's available here: 
https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd

I've posted the current draft below.

Thanks,
Harlan Haskins

Disallow Optionals in String Interpolation Segments
Proposal: SE-
Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
Review Manager: TBD
Status: Awaiting revie
Introduction

Swift developers frequently use string interpolation as a convenient, concise 
syntax for interweaving variable values with strings. The interpolation 
machinery, however, has surprising behavior in one specific case: Optional. 
If a user puts an optional value into a string interpolation segment, it will 
insert either "Optional("value")" or "nil" in the resulting string. Neither of 
these is particularly desirable, so we propose a warning and fix-it to surface 
solutions to these potential mistakes.

Swift-evolution thread: Discussion thread topic for that proposal

Motivation

The Swift Programming Language defines string interpolation segments as "a way 
to construct a new String value from a mix of constants, variables, literals, 
and expressions". There is one type that runs counter to this definition: 
Optional. The .none case in particular is used to indicate the absence of a 
value. Moreover, its inclusion in interpolation segments leads to the dreaded 
"nil" in output that is often fed to UI elements. Even barring that, 
interpolating a non-nil optional value yields "Optional("value")", a result 
that is not useful even in logged output.

Given that the Optional type is never fit for display to the end user, and can 
often be a surprising find in the console, we propose that requesting an 
Optional's debug description be an explicit act. This proposal now requires a 
warning when using an expression of Optional type within a string interpolation 
segment.

Proposed solution

The user will be warned after attempting to use an expression with type 
Optional in a string interpolation segment. They will then be offered a 
fixit suggesting they explicitly request the debugDescription of the Optional 
value instead.

Detailed design

Semantic analysis currently does not do much but guarantee the well-formedness 
of expressions in interpolation segments. These are then fed directly to 
String.init(stringInterpolationSegment:) and are run through the runtime 
reflection system to generate a description. Semantic analysis will be tweaked 
to inspect the result of solving an interpolation segment for an Optional and 
will offer a fixit in that case.

Impact on existing code

As this is a warning, code written before this proposal will continue to 
compile and run with the same semantics as before. Authors of code that makes 
use of this unsafe pattern will be offered a migration path to the safer, more 
explicit form.

Alternatives considered

A fixit that suggests a default value be inserted would be entirely appropriate 
(following the style of the fixit introduced in SE-0140).

Forbidding this pattern by hard error would make this proposal a breaking 
change that is out of scope for this stage of Swift's development.

A fixit that introduces a force-unwrapping would technically work as well, 
however it would be fixing a dangerous operation with yet another dangerous 
operation.



Sent from my iPad___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

We now emit a warning whenever an optional is used as an Any. I disagree that 
this should be an error, but it seems reasonable to warn (if we don't already 
thanks to the 'Any' warning).

-Joe

> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio Carrettoni 
> , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
> 
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
> 
>  
> Proposed
>  solution
> 
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
> 
>  
> Detailed
>  design
> 
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
> 
>  
> Impact
>  on existing code
> 
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
> 
>  
> Alternatives
>  considered
> 
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140 
> ).
> 
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
> 
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> operation.
> 
> 
> 
> Sent from my iPad
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> http

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

[Harlan Haskins via swift-evolution]

Unfortunately, Optional-to-Any does not currently hit this case because IIRC it 
doesn't promote to Any in an interpolation segment. I tested this with a ToT 
build yesterday.

- Harlan

> On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
> 
> We now emit a warning whenever an optional is used as an Any. I disagree that 
> this should be an error, but it seems reasonable to warn (if we don't already 
> thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>> mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as "a 
>> way to construct a new String value from a mix of constants, variables, 
>> literals, and expressions". There is one type that runs counter to this 
>> definition: Optional. The .none case in particular is used to indicate the 
>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>> barring that, interpolating a non-nil optional value yields 
>> "Optional("value")", a result that is not useful even in logged output.
>> 
>> Given that the Optional type is never fit for display to the end user, and 
>> can often be a surprising find in the console, we propose that requesting an 
>> Optional's debug description be an explicit act. This proposal now requires 
>> a warning when using an expression of Optional type within a string 
>> interpolation segment.
>> 
>> Proposed solution
>> 
>> The user will be warned after attempting to use an expression with type 
>> Optional in a string interpolation segment. They will then be offered a 
>> fixit suggesting they explicitly request the debugDescription of the 
>> Optional value instead.
>> 
>> Detailed design
>> 
>> Semantic analysis currently does not do much but guarantee the 
>> well-formedness of expressions in interpolation segments. These are then fed 
>> directly to String.init(stringInterpolationSegment:) and are run through the 
>> runtime reflection system to generate a description. Semantic analysis will 
>> be tweaked to inspect the result of solving an interpolation segment for an 
>> Optional and will offer a fixit in that case.
>> 
>> Impact on existing code
>> 
>> As this is a warning, code written before this proposal will continue to 
>> compile and run with the same semantics as before. Authors of code that 
>> makes use of this unsafe pattern will be offered a migration path to the 
>> safer, more explicit form.
>> 
>> Alternatives considered
>> 
>> A fixit that suggests a default value be inserted would be entirely 
>> appropriate (following the style of the fixit introduced in SE-0140).
>> 
>> Forbidding this pattern by hard error would make this proposal a breaking 
>> change that is out of scope for this stage of Swift's development.
>> 
>> A fixit that introduces a force-unwrapping would technically work as well, 
>> however it would be fixing a dangerous operation with yet another dangerous 
>> operation.
>> 
>> 
>> 
>> Sent from my iPad
>> ___
>> 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 draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

Because the initializer here doesn’t take Any, it takes .

~Robert Widmann

> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Unfortunately, Optional-to-Any does not currently hit this case because IIRC 
> it doesn't promote to Any in an interpolation segment. I tested this with a 
> ToT build yesterday.
> 
> - Harlan
> 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  > wrote:
> 
>> We now emit a warning whenever an optional is used as an Any. I disagree 
>> that this should be an error, but it seems reasonable to warn (if we don't 
>> already thanks to the 'Any' warning).
>> 
>> -Joe
>> 
>>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hey all,
>>> 
>>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>>> mitigate something that's burned us all since Swift 1. We'd love some 
>>> feedback!
>>> 
>>> It's available here: 
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>>> 
>>> 
>>> I've posted the current draft below.
>>> 
>>> Thanks,
>>> Harlan Haskins
>>> 
>>> Disallow Optionals in String Interpolation Segments
>>> 
>>> Proposal: SE- 
>>> Authors: Harlan Haskins , Julio 
>>> Carrettoni , Robert Widmann 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting revie
>>>  
>>> Introduction
>>> 
>>> Swift developers frequently use string interpolation as a convenient, 
>>> concise syntax for interweaving variable values with strings. The 
>>> interpolation machinery, however, has surprising behavior in one specific 
>>> case: Optional. If a user puts an optional value into a string 
>>> interpolation segment, it will insert either "Optional("value")" or "nil" 
>>> in the resulting string. Neither of these is particularly desirable, so we 
>>> propose a warning and fix-it to surface solutions to these potential 
>>> mistakes.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal 
>>> 
>>>  
>>> Motivation
>>> 
>>> The Swift Programming Language defines string interpolation segments as "a 
>>> way to construct a new String value from a mix of constants, variables, 
>>> literals, and expressions". There is one type that runs counter to this 
>>> definition: Optional. The .none case in particular is used to indicate the 
>>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>>> barring that, interpolating a non-nil optional value yields 
>>> "Optional("value")", a result that is not useful even in logged output.
>>> 
>>> Given that the Optional type is never fit for display to the end user, and 
>>> can often be a surprising find in the console, we propose that requesting 
>>> an Optional's debug description be an explicit act. This proposal now 
>>> requires a warning when using an expression of Optional type within a 
>>> string interpolation segment.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> The user will be warned after attempting to use an expression with type 
>>> Optional in a string interpolation segment. They will then be offered a 
>>> fixit suggesting they explicitly request the debugDescription of the 
>>> Optional value instead.
>>> 
>>>  
>>> Detailed
>>>  design
>>> 
>>> Semantic analysis currently does not do much but guarantee the 
>>> well-formedness of expressions in interpolation segments. These are then 
>>> fed directly to String.init(stringInterpolationSegment:) and are run 
>>> through the runtime reflection system to generate a description. Semantic 
>>> analysis will be tweaked to inspect the result of solving an interpolation 
>>> segment for an Optional and will offer a fixit in that case.
>>> 
>>>  
>>> Impact
>>>  on existing code
>>> 
>>> As this is a warning, code written before this proposal will continue to 
>>> compile and run with the same semantics as before. Authors of code that 
>>> makes use of this unsafe pattern will be offered a migration path to the 
>>> safer, more explicit form.
>>> 
>>>  
>>> Alternatives
>>>  considered
>>> 
>>> A fixit that suggests a default value 

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

[Keith Smiley via swift-evolution]

+1 to this warning. We've been hit by this bug a bunch of times. Especially when
optionality of properties have been in flux.

Just yesterday: https://twitter.com/zefhous/status/782783999663943680

--
Keith Smiley

On 10/03, Harlan Haskins via swift-evolution wrote:
> Hey all,
>
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
>
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>
> I've posted the current draft below.
>
> Thanks,
> Harlan Haskins
>
> Disallow Optionals in String Interpolation Segments
> Proposal: SE-
> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
> Review Manager: TBD
> Status: Awaiting revie
> Introduction
>
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
>
> Swift-evolution thread: Discussion thread topic for that proposal
>
> Motivation
>
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
>
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
>
> Proposed solution
>
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
>
> Detailed design
>
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
>
> Impact on existing code
>
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
>
> Alternatives considered
>
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140).
>
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
>
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> operation.
>
>
>
> Sent from my iPad

> ___
> 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 draft] Disallow Optionals in String Interpolation Segments

[Joe Groff via swift-evolution]

> On Oct 3, 2016, at 11:02 AM, Robert Widmann  wrote:
> 
> Because the initializer here doesn’t take Any, it takes .

I think there's a case to be made to generalize the 'Any' warning to Optional 
implicitly being deduced as a type variable binding in any unconstrained 
context. What exactly constitutes 'implicit' and 'unconstrained' is up for 
debate, though, and probably needs some experimentation to figure out what 
feels good. For instance, explicitly constructing an optional is a signal the 
optionality intentional. Potentially, having multiple Optional parameters 
binding the same type variable also increases the likelihood it's intended, for 
example:

func foo(x: T, y: T) {}

var x: Int? = 1
var y: Int = 2
foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. Maybe 
a mistake?
var z: Int? = 3
foo(x, z) // Two T parameters are Optional. Probably intentional?

Regardless of whether there's a more general principle we can base a warning 
on, string interpolation and String(describing:) are common enough pitfalls 
that they may just deserve special case treatment.

-Joe

> ~Robert Widmann
> 
>> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Unfortunately, Optional-to-Any does not currently hit this case because IIRC 
>> it doesn't promote to Any in an interpolation segment. I tested this with a 
>> ToT build yesterday.
>> 
>> - Harlan
>> 
>> On Oct 3, 2016, at 1:57 PM, Joe Groff > > wrote:
>> 
>>> We now emit a warning whenever an optional is used as an Any. I disagree 
>>> that this should be an error, but it seems reasonable to warn (if we don't 
>>> already thanks to the 'Any' warning).
>>> 
>>> -Joe
>>> 
 On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hey all,
 
 Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
 mitigate something that's burned us all since Swift 1. We'd love some 
 feedback!
 
 It's available here: 
 https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
 
 
 I've posted the current draft below.
 
 Thanks,
 Harlan Haskins
 
 Disallow Optionals in String Interpolation Segments
 
 Proposal: SE- 
 Authors: Harlan Haskins , Julio 
 Carrettoni , Robert Widmann 
 
 Review Manager: TBD
 Status: Awaiting revie
  
 Introduction
 
 Swift developers frequently use string interpolation as a convenient, 
 concise syntax for interweaving variable values with strings. The 
 interpolation machinery, however, has surprising behavior in one specific 
 case: Optional. If a user puts an optional value into a string 
 interpolation segment, it will insert either "Optional("value")" or "nil" 
 in the resulting string. Neither of these is particularly desirable, so we 
 propose a warning and fix-it to surface solutions to these potential 
 mistakes.
 
 Swift-evolution thread: Discussion thread topic for that proposal 
 
  
 Motivation
 
 The Swift Programming Language defines string interpolation segments as "a 
 way to construct a new String value from a mix of constants, variables, 
 literals, and expressions". There is one type that runs counter to this 
 definition: Optional. The .none case in particular is used to indicate the 
 absence of a value. Moreover, its inclusion in interpolation segments 
 leads to the dreaded "nil" in output that is often fed to UI elements. 
 Even barring that, interpolating a non-nil optional value yields 
 "Optional("value")", a result that is not useful even in logged output.
 
 Given that the Optional type is never fit for display to the end user, and 
 can often be a surprising find in the console, we propose that requesting 
 an Optional's debug description be an explicit act. This proposal now 
 requires a warning when using an expression of Optional type within a 
 string interpolation segment.
 
  
 Proposed
  solution
 
 The user will be warned after attempting to use an expression with type 
 Optional in a string interpolation segment. They will then be offered a 
 fixit suggesting they explicitly request the debugDescription of the 
 Optional value ins

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

[Ben Rimmington via swift-evolution]

Instead of using `fatalError(_:file:line:)` in `default` cases, would a public 
`unreachable()` function be more efficient?

e.g. 

-- Ben

> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
>  wrote:
> 
> -1 from me too.
> 
> Avoiding having to write "default: break" isn't a good justification to 
> introduce new syntax. It would make the understanding of case switches harder 
> without providing any real benefit for the syntax bloat.
> 
> João Pinheiro
> 
> 
>> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> -1 from me as well. This suggestion falls into the same category as those 
>> about making `else` optional after `guard`, which is repeatedly rejected. 
>> Since code is read more often than written, explicit handling of the default 
>> case never hurts and can increase clarity. Not having to write `default: 
>> break` offers no help in writing correct code and IMO can't justify new 
>> syntax or the changing of a well-known control statement.
>> 
>> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
>> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
>> they’re clearly in the domain of possible values that can be fed to a 
>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>> does happen to go wrong, and makes it much easier to verify the correctness 
>> of the flow of control of the containing block because all points from the 
>> switch must be covered.  We also don’t have the type-level tools to convince 
>> the checker to allow you to remove unreachable cases.  If it’s really a 
>> problem that you are writing default cases everywhere, just bailout in a 
>> fatal error with a nice description.  It never hurts.
>> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I know that there is this note in Commonly Rejected Changes 
>>> :
>>> 
>>> Remove support for default: in switch and just use case _:: default is 
>>> widely used, case _ is too magical, and default is widely precedented in 
>>> many C family languages.
>>> I really like to use the switch instead of if case for pattern matching, 
>>> just because it’s neat block design. I do not want to remove default from 
>>> switches because it’s a must have and powerful feature.
>>> 
>>> I’d like to know why switches must be exhaustive. 
>>> 
>>> switch someValue {
>>>  
>>> case …:
>>> // Do something
>>>  
>>> case …:
>>> // Do something else
>>> 
>>> default:  
>>> () // useless nop; do nothing when no pattern matched
>>> }
>>> 
>>> // VS:
>>> 
>>> if case … {
>>>  
>>> } else if case … {
>>>  
>>> } else if case … {
>>>  
>>> } // No need for `else`
>>> Can’t we make default optional, or at least on non-enum values?
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

fatalError has defaults for its arguments so it can be used as a nullary 
unreachable function already.

~Robert Widmann

> On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> Instead of using `fatalError(_:file:line:)` in `default` cases, would a 
> public `unreachable()` function be more efficient?
> 
> e.g.  >
> 
> -- Ben
> 
>> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> -1 from me too.
>> 
>> Avoiding having to write "default: break" isn't a good justification to 
>> introduce new syntax. It would make the understanding of case switches 
>> harder without providing any real benefit for the syntax bloat.
>> 
>> João Pinheiro
>> 
>> 
>>> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> -1 from me as well. This suggestion falls into the same category as those 
>>> about making `else` optional after `guard`, which is repeatedly rejected. 
>>> Since code is read more often than written, explicit handling of the 
>>> default case never hurts and can increase clarity. Not having to write 
>>> `default: break` offers no help in writing correct code and IMO can't 
>>> justify new syntax or the changing of a well-known control statement.
>>> 
>>> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
>>> be able to ignore cases that “can’t happen” (so say we, writer of bugs) 
>>> when they’re clearly in the domain of possible values that can be fed to a 
>>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>>> does happen to go wrong, and makes it much easier to verify the correctness 
>>> of the flow of control of the containing block because all points from the 
>>> switch must be covered.  We also don’t have the type-level tools to 
>>> convince the checker to allow you to remove unreachable cases.  If it’s 
>>> really a problem that you are writing default cases everywhere, just 
>>> bailout in a fatal error with a nice description.  It never hurts.
>>> 
>>> ~Robert Widmann
>>> 
 On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I know that there is this note in Commonly Rejected Changes 
 :
 
 Remove support for default: in switch and just use case _:: default is 
 widely used, case _ is too magical, and default is widely precedented in 
 many C family languages.
 I really like to use the switch instead of if case for pattern matching, 
 just because it’s neat block design. I do not want to remove default from 
 switches because it’s a must have and powerful feature.
 
 I’d like to know why switches must be exhaustive. 
 
 switch someValue {
  
 case …:
 // Do something
  
 case …:
 // Do something else
 
 default:  
 () // useless nop; do nothing when no pattern matched
 }
 
 // VS:
 
 if case … {
  
 } else if case … {
  
 } else if case … {
  
 } // No need for `else`
 Can’t we make default optional, or at least on non-enum values?
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
> ___
> 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 draft] Conditional conformances

[Alexis via swift-evolution]

Below I’ve provided a more fleshed out version of what Dave is suggesting, for 
anyone who had trouble parsing the very hypothetical example. It reflects the 
kind of implementation specialization I would expect to see in the standard 
library. In fact we have exactly this concern baked into value witness tables 
today by differentiating the various *Buffer methods so that they can be no-ops 
or memcpys for trivial values (rather than requiring code to loop over all the 
elements and call potentially-no-op methods on each element).

But the value witness table’s approach to this problem suggests some healthier 
solutions to the problem (for Swift’s particular set of constraints):

1) Add default-implemented fullAlgorithm() methods to the protocol. Anyone who 
can beat the default algorithm provides their own implementation. Consumers of 
the protocol then dispatch to fullAlgorithm(), rather than the lower-level 
primitives.

2) Add “let hasInterestingProperty: bool” flags to the protocol. Consumers of 
the protocol can then branch on these flags to choose a “slow generic” or “fast 
specific” implementation. (this is, after all, exactly what we’re asking the 
runtime to do for us!)

Of course, (1) and (2) aren’t always applicable solutions. Both only really 
apply if you’re the original creator of the protocol; otherwise no one will 
know about fullAlgorithm or hasInterestingProperty and be able to modify the 
default. It can also be really tedious to provide your own implementation of 
fullAlgorithm(), especially if everyone overloads it in the same way. These 
are, however, perfectly reasonable approaches if you’re just trying to 
specialize for a small, closed, set of types. Something like:

genericImpl()
stringImpl()
intImpl()

You can handle that pretty easily with extensions or super-protocols, I think.

I’m cautiously optimistic we can get pretty far before we really feel the need 
to introduce specialization like this. Although I’m used to handling this issue 
in a world of monomorphic generics; so I’m not sure if the performance 
characteristics of polymorphic generics will shift the balance to making 
specialization more urgent. Or perhaps the opposite — the runtime impact of 
specialization could be too high!


// Some kind of "super copy" operation
public protocol Clone {
  func clone() -> Self
}

// Can just memcpy instead of calling Clone
public protocol TrivialClone: Clone { }

// A terrible data structure
public struct FakeArray { let vals: (T, T, T) }



// --
// A dirty hack to get overlapping impls (specifically specialization)
// through overlapping extensions.

internal protocol CloneImpl {
  associatedtype TT: Clone
}

extension CloneImpl {
  static func clone(input: FakeArray) -> FakeArray {
// Have to manually invoke generic `clone` on each element
FakeArray(vals: (input.vals.0.clone(),
 input.vals.1.clone(),
 input.vals.2.clone()))
  }
}

extension CloneImpl where TT: TrivialClone {
  static func clone(input: FakeArray) -> FakeArray {
// Can just copy the whole buffer at once (ideally a memcpy)
FakeArray(vals: input.vals)
  }
}


// Inject our specialized Clone impl
// (doesn't compile today because this is a conditional conformance)
extension FakeArray: Clone where T: Clone {
  // A dummy to get our overlapping extensions
  // (doesn't compile today because we can't nest types in a generic type)
  struct CloneImplProvider : CloneImpl {
typealias TT = T
  }
  
  func clone() -> FakeArray {
CloneImplProvider.clone(input: self)
  }
}

// -
// Using Clone and the specialization

// Some plain-old-data
struct POD : TrivialClone {
  func clone() -> POD { return self }
}

// Works with any Clone type
func generic(_ value: T) -> T {
  return value.clone()
}

// Pass in a FakeArray that should use the fast specialization for Clone
generic(FakeArray(vals: (POD(), POD(), POD(




> On Sep 30, 2016, at 11:18 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Sep 30 2016, Matthew Johnson  wrote:
> 
>>> It’s a valid concern, and I’m sure it does come up in practice. Let’s 
>>> create a small, self-contained example:
>>> 
>>> protocol P {
>>>  func f()
>>> }
>>> 
>>> protocol Q: P { }
>>> 
>>> struct X { let t: T}
>>> 
>>> extension X: P where T: P {
>>>  func f() {
>>>/* general but slow */
>>>  }
>>> }
>>> 
>>> extension X where T: Q {
>>>  func f() {
>>>/* fast because it takes advantage of T: Q */
>>>  }
>>> }
>>> 
>>> struct IsQ : Q { }
>>> 
>>> func generic(_ value: u) {
>>>  value.f()
>>> }
>>> 
>>> generic(X())
>>> 
>>> We’d like for the call to “value.f()” to get the fast version of f()
>>> from the second extension, but the proposal doesn’t do that: the
>>> conformance to P is “locked in” to the first extension.
> 
> I suppose that's true even if the second extension introduces X : Q?
> 
>>> If we assume 

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

[Ben Rimmington via swift-evolution]

Yes, but  uses 
`Builtin.unreachable()` because it:

> "Saves a bit of code size in the standard library by eliminating some
> static strings and function calls."

Clang has both `__builtin_unreachable()` and `llvm_unreachable()`:





-- Ben

> On 3 Oct 2016, at 20:01, Robert Widmann  wrote:
> 
> fatalError has defaults for its arguments so it can be used as a nullary 
> unreachable function already.
> 
> ~Robert Widmann
> 
>> On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Instead of using `fatalError(_:file:line:)` in `default` cases, would a 
>> public `unreachable()` function be more efficient?
>> 
>> e.g. > >
>> 
>> -- Ben
>> 
>>> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> -1 from me too.
>>> 
>>> Avoiding having to write "default: break" isn't a good justification to 
>>> introduce new syntax. It would make the understanding of case switches 
>>> harder without providing any real benefit for the syntax bloat.
>>> 
>>> João Pinheiro
>>> 
>>> 
 On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 -1 from me as well. This suggestion falls into the same category as those 
 about making `else` optional after `guard`, which is repeatedly rejected. 
 Since code is read more often than written, explicit handling of the 
 default case never hurts and can increase clarity. Not having to write 
 `default: break` offers no help in writing correct code and IMO can't 
 justify new syntax or the changing of a well-known control statement.
 
 On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 -1 in general.  I want smarter exhaustiveness analysis, but I don’t want 
 to be able to ignore cases that “can’t happen” (so say we, writer of bugs) 
 when they’re clearly in the domain of possible values that can be fed to a 
 switch-case.  Exhaustiveness guarantees wellformedness of a program that 
 does happen to go wrong, and makes it much easier to verify the 
 correctness of the flow of control of the containing block because all 
 points from the switch must be covered.  We also don’t have the type-level 
 tools to convince the checker to allow you to remove unreachable cases.  
 If it’s really a problem that you are writing default cases everywhere, 
 just bailout in a fatal error with a nice description.  It never hurts.
 
 ~Robert Widmann
 
> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> I know that there is this note in Commonly Rejected Changes 
> :
> 
> Remove support for default: in switch and just use case _:: default is 
> widely used, case _ is too magical, and default is widely precedented in 
> many C family languages.
> I really like to use the switch instead of if case for pattern matching, 
> just because it’s neat block design. I do not want to remove default from 
> switches because it’s a must have and powerful feature.
> 
> I’d like to know why switches must be exhaustive. 
> 
> switch someValue {
>  
> case …:
> // Do something
>  
> case …:
> // Do something else
> 
> default:  
> () // useless nop; do nothing when no pattern matched
> }
> 
> // VS:
> 
> if case … {
>  
> } else if case … {
>  
> } else if case … {
>  
> } // No need for `else`
> Can’t we make default optional, or at least on non-enum values?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

-1. The “default: break” is not only not difficult to write, it clearly 
communicates the programmer’s intent to only handle a subset of the cases. 
Without it, it is impossible to know whether that was intended, or by accident. 
Furthermore, the exhaustiveness by default can catch many mistakes, including 
after an additional case is added to an enum.

Charles

> On Oct 3, 2016, at 5:14 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I know that there is this note in Commonly Rejected Changes 
> :
> 
> Remove support for default: in switch and just use case _:: default is widely 
> used, case _ is too magical, and default is widely precedented in many C 
> family languages.
> I really like to use the switch instead of if case for pattern matching, just 
> because it’s neat block design. I do not want to remove default from switches 
> because it’s a must have and powerful feature.
> 
> I’d like to know why switches must be exhaustive. 
> 
> switch someValue {
>  
> case …:
> // Do something
>  
> case …:
> // Do something else
> 
> default:  
> () // useless nop; do nothing when no pattern matched
> }
> 
> // VS:
> 
> if case … {
>  
> } else if case … {
>  
> } else if case … {
>  
> } // No need for `else`
> Can’t we make default optional, or at least on non-enum values?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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] [Pitch] Can we make `default` on switches optional?

[Robert Widmann via swift-evolution]

If you're as concerned about code size as stdlib is then I'd be interested to 
know what you're writing!  These are paths to terminate your application which 
is necessarily going to be orders of magnitude larger than stdlib is and so can 
"eat the cost" of a few more global db's, some loads, and a call or three.  

~Robert Widmann

2016/10/03 15:14、Ben Rimmington  のメッセージ:

> Yes, but  uses 
> `Builtin.unreachable()` because it:
> 
>> "Saves a bit of code size in the standard library by eliminating some
>> static strings and function calls."
> 
> Clang has both `__builtin_unreachable()` and `llvm_unreachable()`:
> 
> 
> 
> 
> 
> -- Ben
> 
>> On 3 Oct 2016, at 20:01, Robert Widmann  wrote:
>> 
>> fatalError has defaults for its arguments so it can be used as a nullary 
>> unreachable function already.
>> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution 
>>>  wrote:
>>> 
>>> Instead of using `fatalError(_:file:line:)` in `default` cases, would a 
>>> public `unreachable()` function be more efficient?
>>> 
>>> e.g. 
>>> 
>>> -- Ben
>>> 
 On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
  wrote:
 
 -1 from me too.
 
 Avoiding having to write "default: break" isn't a good justification to 
 introduce new syntax. It would make the understanding of case switches 
 harder without providing any real benefit for the syntax bloat.
 
 João Pinheiro
 
 
> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> -1 from me as well. This suggestion falls into the same category as those 
> about making `else` optional after `guard`, which is repeatedly rejected. 
> Since code is read more often than written, explicit handling of the 
> default case never hurts and can increase clarity. Not having to write 
> `default: break` offers no help in writing correct code and IMO can't 
> justify new syntax or the changing of a well-known control statement.
> 
> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
>  wrote:
>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want 
>> to be able to ignore cases that “can’t happen” (so say we, writer of 
>> bugs) when they’re clearly in the domain of possible values that can be 
>> fed to a switch-case.  Exhaustiveness guarantees wellformedness of a 
>> program that does happen to go wrong, and makes it much easier to verify 
>> the correctness of the flow of control of the containing block because 
>> all points from the switch must be covered.  We also don’t have the 
>> type-level tools to convince the checker to allow you to remove 
>> unreachable cases.  If it’s really a problem that you are writing 
>> default cases everywhere, just bailout in a fatal error with a nice 
>> description.  It never hurts.
>> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> I know that there is this note in Commonly Rejected Changes:
>>> 
>>> Remove support for default: in switch and just use case _:: default is 
>>> widely used, case _ is too magical, and default is widely precedented 
>>> in many C family languages.
>>> I really like to use the switch instead of if case for pattern 
>>> matching, just because it’s neat block design. I do not want to remove 
>>> default from switches because it’s a must have and powerful feature.
>>> 
>>> I’d like to know why switches must be exhaustive. 
>>> 
>>> switch someValue {
>>>  
>>> case …:
>>> // Do something
>>>  
>>> case …:
>>> // Do something else
>>> 
>>> default:  
>>> () // useless nop; do nothing when no pattern matched
>>> }
>>> 
>>> // VS:
>>> 
>>> if case … {
>>>  
>>> } else if case … {
>>>  
>>> } else if case … {
>>>  
>>> } // No need for `else`
>>> Can’t we make default optional, or at least on non-enum values?
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Dave Abrahams via swift-evolution]

on Mon Oct 03 2016, Alexis  wrote:

> Below I’ve provided a more fleshed out version of what Dave is
> suggesting, for anyone who had trouble parsing the very hypothetical
> example. It reflects the kind of implementation specialization I would
> expect to see in the standard library. 

Thanks, Alexis.

Doug and I talked this morning and fortunately I think we came up with
something rational that will support the kind of specialization we want
without any hoop-jumping.  It basically involves precomputing the
overload lattice and filling witness tables dynamically based on the
conformances that are statically visible at the moment they are
instantiated.  We'll post more detail soon.

-- 
-Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 Name : String { … }).

Sometimes this is not enough for my use-case and I wish I could feed my enums 
with other Hashable types!

As a workaround I can create a custom struct or even a class and conform it to 
RawRepresentable and fake an enum with some static variables (similar to what 
is done with OptionSet types).

The problem there is that I cannot use the same switch pattern matching like 
with enums. I’d wish either enums could accept Hashable types (maybe with some 
restriction) or the existence on a protocol to build custom enum-like types 
with strucs/classes and use the same switch pattern matching.

struct A : Hashable { /* implement everything */ }

// Variant 1:
enum Test : A {
case something = A(rawValue: A(value: "something"))
case nothing = A(rawValue: A(value: "nothing"))  
}

// Variant 2:

protocol SomeFancyName : RawRepresentable { … }

struct Test : SomeFancyName {
 
let rawValue: A
init?(rawValue: A) {
// Implement + reject unwanted `A`s  
}
 
static let something = A(rawValue: A(value: "something"))
static let nothing = A(rawValue: A(value: "nothing"))
}

let value = Test.something

switch value {
 
case .something:
// handle
 
case .nothing:
// handle
 
// Because of `SomeFancyName` the switch can use enum-like pattern matching + 
does not need the `default` case when all cases are present
}


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Joe Groff via swift-evolution]

> On Oct 2, 2016, at 8:56 AM, Callionica (Swift) via swift-evolution 
>  wrote:
> 
> Interesting comment about worries that you'd be dispatched to the least good 
> SS version . A different language with different constraints, but when LINQ 
> to Objects implementers needed to provide optimized c# implementations for 
> some operations they chose a runtime type check to dispatch to the optimized 
> version. For example, while API is exposed as IEnumerable there are method 
> implementations that check for ICollection at runtime in order to hit more 
> efficient implementations. So static dispatch is good, but win for 
> collections often big enough to overcome a hit from dynamic dispatch. 

Yep, and Swift's specialization optimization already knows how to fold `is` and 
`as` checks after specializing a generic, so checking for a specific type or 
sub-protocol and jumping into a more optimized implementation for that subtype 
"dynamically" is still likely to be optimized away.

-Joe

> On Sunday, October 2, 2016, plx via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Sep 30, 2016, at 1:23 PM, Douglas Gregor > > wrote:
>>> 
>>> This is purely anecdotal but I had a lot of utility code laying around that 
>>> I’d marked with notes like `// TODO: revisit once conditional conformances 
>>> are available`.
>>> 
>>> When I was leaving those notes I was expecting to need overlapping 
>>> conformances often, but I reviewed them *before* replying and I actually 
>>> haven’t found an example where having overlapping conformances is both (1) 
>>> a significant win and also (2) a win in a way that’d be of broad, general 
>>> interest.
>>> 
>>> - 80% have no real need for overlapping conditional conformances
>>> - 15% might have “elegance gains” but nothing practically-significant
>>> - 5% would *probably* see real gains but are likely not of broad interest
>>> 
>>> …which wasn’t what I was expecting, but leaves me a lot more comfortable 
>>> without overlapping conformances for now than I was in the abstract.
>> 
>> Very interesting, thanks for doing this review!
> 
> I've taken the time to provide a bit more color on the 80/15/5 breakdown 
> because I don't see much discussion for this proposal in terms of concrete 
> situations...just theoretical concerns and theoretical possibilities. I don't 
> have any completed code either, but I have notes and to-do lists for things I 
> was planning to do, and I think seeing even some semi-concrete scenarios 
> might be helpful here.
> 
> The "80%" are generally analogous to the `SomeWrapper` in the writeup; as a 
> concrete example, I was waiting on the availability of conditional 
> conformances to resume work on an emulation of structural unions, e.g. 
> something like:
> 
>   enum Sum2 {
> case a(A)
> case b(B)
>   }
>   
> ...(and analogously for 3, 4, as-necessary). 
> 
> There's a very obvious way to write `extension Sum2 : Equatable where 
> A:Equatable, B:Equatable {}`...and at the time I set this aside, I was 
> expecting to also want to come back and have additional conformances for 
> things like `...where A:Equatable, B:AnyObject` (using `===` for comparing 
> `B`) and so on for other combinations.
> 
> Upon revisiting such things in light of the proposal, I now think 
> differently: for this case it seems like a better long-term approach anyways 
> to stick to a single conformance and work with it like this:
> 
>   extension Sum2:Equatable where A:Equatable, B:Equatable {
> // details elided
>   }
>   
>   /// Adaptor using `ObjectIdentifier` to implement `==`.
>   struct ObjectWrapper : Equatable, Hashable {
> let wrapped: Wrapped
>   }
>   
> ...as upon reflection I really would prefer dealing with the hassle of 
> working with `Sum2>` in situations where -- in theory -- 
> `Sum2` could do -- to the hassle of writing out 4+ conformances for 
> `Sum2` (and so on...even with nice code-gen tools that's going to be a lot of 
> bloat!). 
> 
> What changed my mind was tracing through the implications of conditional 
> conformances for the use-site ergonomics of adaptors like `ObjectWrapper` 
> above; what I mean is, suppose I have a protocol like this:
> 
>   protocol WidgetFactory {
> associatedtype Widget
> associatedtype Material
> 
> func produceWidget(using material: Material) -> Widget
>   }
> 
> ...then it's rather easy to simply write this type of boilerplate:
> 
>   extension ObjectWrapper: WidgetFactory where Wrapped: WidgetFactory {
> typealias Widget = Wrapper.Widget
> typealias Material = Wrapper.Material
> 
> func produceWidget(using material: Material) -> Widget {
>   return base.produceWidget(using: material)
> }
>   }
>   
> ...which thus means I have the tools I need to make my use of wrappers like 
> the `ObjectWrapper` largely transparent at the use sites I care about; e.g. I 
> can write a single conditional conformance like this:
> 
>   extension Sum2: WidgetFactory 
>

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

[Adrian Zubarev via swift-evolution]

I made a typo in my previous post.

Bikeshdding with correct types:

struct A : Hashable { /* implement everything */ }

// Variant 1:
enum Test : A {
case something = A(value: "something")
case nothing = A(value: "nothing")
}

// Variant 2:

protocol SomeFancyName : RawRepresentable { … }

struct Test : SomeFancyName {
  
let rawValue: A
init?(rawValue: A) {
// Implement + reject unwanted `A`s   
}
  
static let something = Test(rawValue: A(value: "something"))
static let nothing = Test(rawValue: A(value: "nothing"))
}

let value = Test.something

switch value {
  
case .something:
// handle
  
case .nothing:
// handle
  
// Because of `SomeFancyName` the switch can use enum-like pattern matching + 
does not need the `default` case when all cases are present
}


-- 
Adrian Zubarev
Sent with Airmail

Am 3. Oktober 2016 um 21:50:07, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

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 Name : String { … }).

Sometimes this is not enough for my use-case and I wish I could feed my enums 
with other Hashable types!

As a workaround I can create a custom struct or even a class and conform it to 
RawRepresentable and fake an enum with some static variables (similar to what 
is done with OptionSet types).

The problem there is that I cannot use the same switch pattern matching like 
with enums. I’d wish either enums could accept Hashable types (maybe with some 
restriction) or the existence on a protocol to build custom enum-like types 
with strucs/classes and use the same switch pattern matching.

struct A : Hashable { /* implement everything */ }

// Variant 1:
enum Test : A {
case something = A(rawValue: A(value: "something"))
case nothing = A(rawValue: A(value: "nothing"))   
}

// Variant 2:

protocol SomeFancyName : RawRepresentable { … }

struct Test : SomeFancyName {
  
let rawValue: A
init?(rawValue: A) {
// Implement + reject unwanted `A`s   
}
  
static let something = A(rawValue: A(value: "something"))
static let nothing = A(rawValue: A(value: "nothing"))
}

let value = Test.something

switch value {
  
case .something:
// handle
  
case .nothing:
// handle
  
// Because of `SomeFancyName` the switch can use enum-like pattern matching + 
does not need the `default` case when all cases are present
}


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mark Lacey via swift-evolution]

> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Oct 3, 2016, at 11:02 AM, Robert Widmann > > wrote:
>> 
>> Because the initializer here doesn’t take Any, it takes .
> 
> I think there's a case to be made to generalize the 'Any' warning to Optional 
> implicitly being deduced as a type variable binding in any unconstrained 
> context. What exactly constitutes 'implicit' and 'unconstrained' is up for 
> debate, though, and probably needs some experimentation to figure out what 
> feels good. For instance, explicitly constructing an optional is a signal the 
> optionality intentional. Potentially, having multiple Optional parameters 
> binding the same type variable also increases the likelihood it's intended, 
> for example:
> 
> func foo(x: T, y: T) {}
> 
> var x: Int? = 1
> var y: Int = 2
> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
> Maybe a mistake?
> var z: Int? = 3
> foo(x, z) // Two T parameters are Optional. Probably intentional?
> 
> Regardless of whether there's a more general principle we can base a warning 
> on, string interpolation and String(describing:) are common enough pitfalls 
> that they may just deserve special case treatment.

I think string interpolation could be handled pretty easily with a warning by 
extending the existing warning for Any. We just need to look at interpolation 
expressions and if any of the segments are optional-typed emit a warning unless 
they are explicitly casted to the optional type. The fixit can suggest explicit 
casting or using the debugDescription.

I’m not sure we really need an evolution proposal for that.

As for the more general topic of trickiness around optional injection into 
unconstrained generics: Yes, we should review that at some point as well. I 
recall seeing at least one concrete complaint about surprising behavior 
resulting from doing this in generic functions, but I cannot find the bug at 
the moment.

Mark


> 
> -Joe
> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Unfortunately, Optional-to-Any does not currently hit this case because 
>>> IIRC it doesn't promote to Any in an interpolation segment. I tested this 
>>> with a ToT build yesterday.
>>> 
>>> - Harlan
>>> 
>>> On Oct 3, 2016, at 1:57 PM, Joe Groff >> > wrote:
>>> 
 We now emit a warning whenever an optional is used as an Any. I disagree 
 that this should be an error, but it seems reasonable to warn (if we don't 
 already thanks to the 'Any' warning).
 
 -Joe
 
> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
> to mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio 
> Carrettoni , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, 
> concise syntax for interweaving variable values with strings. The 
> interpolation machinery, however, has surprising behavior in one specific 
> case: Optional. If a user puts an optional value into a string 
> interpolation segment, it will insert either "Optional("value")" or "nil" 
> in the resulting string. Neither of these is particularly desirable, so 
> we propose a warning and fix-it to surface solutions to these potential 
> mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as 
> "a way to construct a new String value from a mix of constants, 
> variables, literals, and expressions". There is one type that runs 
> counter to this definition: Optional. The .none case in particular is 
> used to indicate the absence of a value. Moreover, its inclusion in 
> interpo

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

[Robert Widmann via swift-evolution]

Definitely right about that, the implementation 

 took all of 10 minutes after extending the OptionalToAnyCoercionWalker.  If 
you’ve got any comments, please let me know there.

~Robert Widmann

> On Oct 3, 2016, at 4:06 PM, Mark Lacey  wrote:
> 
>> 
>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann  
>>> wrote:
>>> 
>>> Because the initializer here doesn’t take Any, it takes .
>> 
>> I think there's a case to be made to generalize the 'Any' warning to 
>> Optional implicitly being deduced as a type variable binding in any 
>> unconstrained context. What exactly constitutes 'implicit' and 
>> 'unconstrained' is up for debate, though, and probably needs some 
>> experimentation to figure out what feels good. For instance, explicitly 
>> constructing an optional is a signal the optionality intentional. 
>> Potentially, having multiple Optional parameters binding the same type 
>> variable also increases the likelihood it's intended, for example:
>> 
>> func foo(x: T, y: T) {}
>> 
>> var x: Int? = 1
>> var y: Int = 2
>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>> Maybe a mistake?
>> var z: Int? = 3
>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>> 
>> Regardless of whether there's a more general principle we can base a warning 
>> on, string interpolation and String(describing:) are common enough pitfalls 
>> that they may just deserve special case treatment.
> 
> I think string interpolation could be handled pretty easily with a warning by 
> extending the existing warning for Any. We just need to look at interpolation 
> expressions and if any of the segments are optional-typed emit a warning 
> unless they are explicitly casted to the optional type. The fixit can suggest 
> explicit casting or using the debugDescription.
> 
> I’m not sure we really need an evolution proposal for that.
> 
> As for the more general topic of trickiness around optional injection into 
> unconstrained generics: Yes, we should review that at some point as well. I 
> recall seeing at least one concrete complaint about surprising behavior 
> resulting from doing this in generic functions, but I cannot find the bug at 
> the moment.
> 
> Mark
> 
> 
>> 
>> -Joe
>> 
>>> ~Robert Widmann
>>> 
 On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
  wrote:
 
 Unfortunately, Optional-to-Any does not currently hit this case because 
 IIRC it doesn't promote to Any in an interpolation segment. I tested this 
 with a ToT build yesterday.
 
 - Harlan
 
 On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
 
> We now emit a warning whenever an optional is used as an Any. I disagree 
> that this should be an error, but it seems reasonable to warn (if we 
> don't already thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>>  • Proposal: SE-
>>  • Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>>  • Review Manager: TBD
>>  • Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warning and fix-it to surface solutions to 
>> these potential mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as 
>> "a way to construct a new String value from a mix of constants, 
>> variables, literals, and expressions". There is one type that runs 
>> counter to this definition: Optional. The .none case in particular is 
>> used to indicate the absence of a value. Moreover, its inclusion in 
>> interpolation segments leads to the dreaded "nil" in output that is 
>> often fed to UI elements. Eve

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

[Harlan Haskins via swift-evolution]

If you don't think this needs a proposal, then Robert has an implementation 
almost done. We could submit a PR later today.

- Harlan

> On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution 
>  wrote:
> 
> 
>>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann  
>>> wrote:
>>> 
>>> Because the initializer here doesn’t take Any, it takes .
>> 
>> I think there's a case to be made to generalize the 'Any' warning to 
>> Optional implicitly being deduced as a type variable binding in any 
>> unconstrained context. What exactly constitutes 'implicit' and 
>> 'unconstrained' is up for debate, though, and probably needs some 
>> experimentation to figure out what feels good. For instance, explicitly 
>> constructing an optional is a signal the optionality intentional. 
>> Potentially, having multiple Optional parameters binding the same type 
>> variable also increases the likelihood it's intended, for example:
>> 
>> func foo(x: T, y: T) {}
>> 
>> var x: Int? = 1
>> var y: Int = 2
>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>> Maybe a mistake?
>> var z: Int? = 3
>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>> 
>> Regardless of whether there's a more general principle we can base a warning 
>> on, string interpolation and String(describing:) are common enough pitfalls 
>> that they may just deserve special case treatment.
> 
> I think string interpolation could be handled pretty easily with a warning by 
> extending the existing warning for Any. We just need to look at interpolation 
> expressions and if any of the segments are optional-typed emit a warning 
> unless they are explicitly casted to the optional type. The fixit can suggest 
> explicit casting or using the debugDescription.
> 
> I’m not sure we really need an evolution proposal for that.
> 
> As for the more general topic of trickiness around optional injection into 
> unconstrained generics: Yes, we should review that at some point as well. I 
> recall seeing at least one concrete complaint about surprising behavior 
> resulting from doing this in generic functions, but I cannot find the bug at 
> the moment.
> 
> Mark
> 
> 
>> 
>> -Joe
>> 
>>> ~Robert Widmann
>>> 
 On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
  wrote:
 
 Unfortunately, Optional-to-Any does not currently hit this case because 
 IIRC it doesn't promote to Any in an interpolation segment. I tested this 
 with a ToT build yesterday.
 
 - Harlan
 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
> 
> We now emit a warning whenever an optional is used as an Any. I disagree 
> that this should be an error, but it seems reasonable to warn (if we 
> don't already thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warning and fix-it to surface solutions to 
>> these potential mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as 
>> "a way to construct a new String value from a mix of constants, 
>> variables, literals, and expressions". There is one type that runs 
>> counter to this definition: Optional. The .none case in particular is 
>> used to indicate the absence of a value. Moreover, its inclusion in 
>> interpolation segments leads to the dreaded "nil" in output that is 
>> often fed to UI elements. Even barring that, interpolating a non-nil 
>> optional value yields "Optional("value")", a result that is not useful 
>> even in logged output.
>> 
>> Given

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

[Mark Lacey via swift-evolution]

> On Oct 3, 2016, at 2:12 PM, Harlan Haskins  wrote:
> 
> If you don't think this needs a proposal

Well, that’s not up to me, so let’s wait until someone else chimes in. :)

Mark

> , then Robert has an implementation almost done. We could submit a PR later 
> today.
> 
> - Harlan
> 
> On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Oct 3, 2016, at 11:02 AM, Robert Widmann >>> > wrote:
 
 Because the initializer here doesn’t take Any, it takes .
>>> 
>>> I think there's a case to be made to generalize the 'Any' warning to 
>>> Optional implicitly being deduced as a type variable binding in any 
>>> unconstrained context. What exactly constitutes 'implicit' and 
>>> 'unconstrained' is up for debate, though, and probably needs some 
>>> experimentation to figure out what feels good. For instance, explicitly 
>>> constructing an optional is a signal the optionality intentional. 
>>> Potentially, having multiple Optional parameters binding the same type 
>>> variable also increases the likelihood it's intended, for example:
>>> 
>>> func foo(x: T, y: T) {}
>>> 
>>> var x: Int? = 1
>>> var y: Int = 2
>>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>>> Maybe a mistake?
>>> var z: Int? = 3
>>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>>> 
>>> Regardless of whether there's a more general principle we can base a 
>>> warning on, string interpolation and String(describing:) are common enough 
>>> pitfalls that they may just deserve special case treatment.
>> 
>> I think string interpolation could be handled pretty easily with a warning 
>> by extending the existing warning for Any. We just need to look at 
>> interpolation expressions and if any of the segments are optional-typed emit 
>> a warning unless they are explicitly casted to the optional type. The fixit 
>> can suggest explicit casting or using the debugDescription.
>> 
>> I’m not sure we really need an evolution proposal for that.
>> 
>> As for the more general topic of trickiness around optional injection into 
>> unconstrained generics: Yes, we should review that at some point as well. I 
>> recall seeing at least one concrete complaint about surprising behavior 
>> resulting from doing this in generic functions, but I cannot find the bug at 
>> the moment.
>> 
>> Mark
>> 
>> 
>>> 
>>> -Joe
>>> 
 ~Robert Widmann
 
> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Unfortunately, Optional-to-Any does not currently hit this case because 
> IIRC it doesn't promote to Any in an interpolation segment. I tested this 
> with a ToT build yesterday.
> 
> - Harlan
> 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  > wrote:
> 
>> We now emit a warning whenever an optional is used as an Any. I disagree 
>> that this should be an error, but it seems reasonable to warn (if we 
>> don't already thanks to the 'Any' warning).
>> 
>> -Joe
>> 
>>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hey all,
>>> 
>>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>>> to mitigate something that's burned us all since Swift 1. We'd love 
>>> some feedback!
>>> 
>>> It's available here: 
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>>> 
>>> 
>>> I've posted the current draft below.
>>> 
>>> Thanks,
>>> Harlan Haskins
>>> 
>>> Disallow Optionals in String Interpolation Segments
>>> 
>>> Proposal: SE- 
>>> 
>>> Authors: Harlan Haskins , Julio 
>>> Carrettoni , Robert Widmann 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting revie
>>>  
>>> Introduction
>>> 
>>> Swift developers frequently use string interpolation as a convenient, 
>>> concise syntax for interweaving variable values with strings. The 
>>> interpolation machinery, however, has surprising behavior in one 
>>> specific case: Optional. If a user puts an optional value into a 
>>> string interpolation segment, it will insert either "Optional("value")" 
>>> or "nil" in the resulting string. Neither of these is particularly 
>>> desirable, so we propose a warning and fix-it to surface solutions to 
>

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

[Kevin Ballard via swift-evolution]

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
> interpolation machinery, however, has surprising behavior in one
> specific case: Optional. If a user puts an optional value into a
> string interpolation segment, it will insert either
> "Optional("value")" or "nil" in the resulting string. Neither of these
> is particularly desirable, so we propose a warning and fix-it to
> surface solutions to these potential mistakes.

Is there any way we could instead allow Optionals but just print them
the way we print ImplicitlyUnwrappedOptionals? That's almost always how
I want my Optionals to work when interpolating. To be specific, this
means for .some(x) we just print x, and for .none we print "nil".

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 Sadun  wrote:
>> 
>> > Indices have a specific, fixed meaning in Swift, which are used to create 
>> > valid collection
>> > subscripts. This proposal introduces indexed() to produce a more 
>> > semantically relevant sequence
> by
>
>> > pairing a collection's indices with its members. While it is trivial to 
>> > create a solution in Swift,
>> > the most common developer approach shown here calculates indexes twice:
>> >
>> > extension Collection {
>> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
>> > /// consecutive collection index, and *x* represents an element of
>> > /// the sequence.
>> > func indexed() -> Zip2Sequence {
>> > return zip(indices, self)
>> > }
>> > }
>> 
>> How does this calculate indices twice?
>
> It calculates indices twice for any collection that uses
> IndexingIterator as its iterator. 

Yes.  Not in general; just in that particular case.

> And for collections that doesn't, it still does the moral equivalent,
> because it's calculating an index offset along with whatever work the
> Iterator does to calculate the next element.

Indexing is supposed to be cheap; almost free.  Lazy filtered
collections are an anomaly.  They're arguably not even legal
Collections, because advancing an index may not be O(1).  They exist
because they're useful, but you shouldn't pass them out without
understanding the consequences.

> As an example, if my collection is `someArray.lazy.filter(…)` then
> zip(col.indices, col) will run the filter twice over the collection.

Okay.

>> > Incrementing an index in some collections can be unnecessarily
>> > costly. 
>> 
>> Seems like it's only *unnecessarily* costly in badly implemented
>> collections?
>
> A collection doesn't have to be badly-implemented to have a
> non-trivial cost for calculating the next element. 
> As above, someArray.lazy.filter(…) is a good example of such a
> collection.

Its conformance to Collection is quite sketchy.

>> > In a lazy filtered collection, an index increment is potentially
>> > O(N). We feel this is better addressed introducing a new function into
>> > the Standard Library to provide a more efficient design that avoids
>> > the attractive nuisance of the "obvious" solution.
>> 
>> I am generally opposed to adding this.  The usual solution developers
>> will reach for here is:
>> 
>> for i in x.indices {
>> somethingWith(x[i])
>> }
>> 
>> zip(indices, self) is only suboptimal for lazy filtered sequences, which
>> should be used with care anyhow (see the note here:
>> http://swiftdoc.org/v3.0/type/LazyFilterCollection/).
>
> It's suboptimal for any collection with a non-trivial index.

Which should be an exceedingly rare thing.

>> If you really need a lazy sequence of pairs that's optimal with lazy
>> filtered sequences, 
>> 
>> x.indices.lazy.map { ($0, x[$0]) }
>> 
>> is a good solution and pretty easy to write.
>
> And yet people will write zip(x.indices, x) instead because it's
> shorter and not immediately obvious that it may be suboptimal
> depending on the collection.
>
> Why are you opposed to adding this? 

Mostly because it's additional API complexity, the usefulness appears to
be marginal, and it's optimizing for what should be a rare corner case
(collections that don't conform to efficiency expectations).

I'm not dead-set against adding it, but ATM it doesn't seem like there
are important use-cases that will benefit substantially from having it.
Convince me this is addressing a real need, and we'll talk.  In phase 2
:-).

> The ability to work around its lack doesn't mean it doesn't have
> value, and the fact that the simplest workaround is not the best one
> is I think a good reason to make the easiest solution into the best
> one (by providing .indexed()). Add to that the fact that a lot of
> people probably use .enumerated() to produce indexes when working with
> arrays, and this is a pitfall when working with other types, such as
> ArraySlice which still has Int indexes but is no longer zero-based.

I am also concerned about introducing confusion around the difference
from enumerated().  These methods will have identical semantics for
Array.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Oct 3, 2016, at 14: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 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
> 
> Is there any way we could instead allow Optionals but just print them the way 
> we print ImplicitlyUnwrappedOptionals? That's almost always how I want my 
> Optionals to work when interpolating. To be specific, this means for .some(x) 
> we just print x, and for .none we print "nil".

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 answer here.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Ballard via swift-evolution]

On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>
>> On Oct 3, 2016, at 14:41, Kevin Ballard via swift-evolution > evolut...@swift.org> 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 interpolation machinery, however, has surprising
>>> behavior in one specific case: Optional. If a user puts an
>>> optional value into a string interpolation segment, it will insert
>>> either "Optional("value")" or "nil" in the resulting string. Neither
>>> of these is particularly desirable, so we propose a warning and fix-
>>> it to surface solutions to these potential mistakes.
>>
>> Is there any way we could instead allow Optionals but just print
>> them the way we print ImplicitlyUnwrappedOptionals? That's almost
>> always how I want my Optionals to work when interpolating. To be
>> specific, this means for .some(x) we just print x, and for .none we
>> print "nil".
> 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 answer here.

But you can't write that, unless you're dealing specifically with an
Optional.  If you try you'll get an error:

unnamed.swift:2:19: error: binary operator '??' cannot be applied to
operands of type 'Int?' and 'String'
print("x: \(x ?? "nil")")
~ ^  ~
unnamed.swift:2:19: note: overloads for '??' exist with these partially
matching parameter lists: (T?, @autoclosure () throws -> T), (T?,
@autoclosure () thro
ws -> T?)
print("x: \(x ?? "nil")")
  ^
This leads to writing code like "… \(x.map(String.init(describing:)) ??
"nil")" which is pretty gross.

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

I've already suggested this quite some time back and was told that this doesn't 
need to go through evolution. It's filed here: 
https://bugs.swift.org/browse/SR-1882 

Unfortunately, I haven't had time to look into it myself and I'm unlikely to 
have the time anytime soon...

> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio Carrettoni 
> , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
> 
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
> 
>  
> Proposed
>  solution
> 
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
> 
>  
> Detailed
>  design
> 
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
> 
>  
> Impact
>  on existing code
> 
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
> 
>  
> Alternatives
>  considered
> 
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140 
> ).
> 
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
> 
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> operation.
> 
> 
> 
> Sent from my

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

[Robert Widmann via swift-evolution]

Under our proposal you can return to the old semantics of printing nil with an 
explicit optional cast - one which we will offer to insert for you.

Otherwise if you actually intend for a default value that value would have type 
Int, not String.  Under the current regime if you want to print something 
custom the for nil the way you've got it now you're going to have to go through 
the reflecting initializer anyway so I don't see a problem here.

~Robert Widmann

2016/10/03 19:25、Charlie Monroe via swift-evolution  
のメッセージ:

> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely to 
> have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>> mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as "a 
>> way to construct a new String value from a mix of constants, variables, 
>> literals, and expressions". There is one type that runs counter to this 
>> definition: Optional. The .none case in particular is used to indicate the 
>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>> barring that, interpolating a non-nil optional value yields 
>> "Optional("value")", a result that is not useful even in logged output.
>> 
>> Given that the Optional type is never fit for display to the end user, and 
>> can often be a surprising find in the console, we propose that requesting an 
>> Optional's debug description be an explicit act. This proposal now requires 
>> a warning when using an expression of Optional type within a string 
>> interpolation segment.
>> 
>> Proposed solution
>> 
>> The user will be warned after attempting to use an expression with type 
>> Optional in a string interpolation segment. They will then be offered a 
>> fixit suggesting they explicitly request the debugDescription of the 
>> Optional value instead.
>> 
>> Detailed design
>> 
>> Semantic analysis currently does not do much but guarantee the 
>> well-formedness of expressions in interpolation segments. These are then fed 
>> directly to String.init(stringInterpolationSegment:) and are run through the 
>> runtime reflection system to generate a description. Semantic analysis will 
>> be tweaked to inspect the result of solving an interpolation segment for an 
>> Optional and will offer a fixit in that case.
>> 
>> Impact on existing code
>> 
>> As this is a warning, code written before this proposal will continue to 
>> compile and run with the same semantics as before. Authors of code that 
>> makes use of this unsafe pattern will be offered a migration path to the 
>> safer, more explicit form.
>> 
>> Alternatives considered
>> 
>> A fixit that suggests a default value be inserted would be entirely 
>> appropriate (following the style of the fixit introduced in SE-0140).
>> 
>> Forbidding this pattern by hard error would make this proposal a breaking 
>> change that is out of scope for this stage of Swift's development.
>> 
>> A fixit that introduces a force-unwrapping would technically work as well, 
>> however it would be fixing a dangerous operation with yet another dangerous 
>> operation.
>> 
>> 
>> 
>> Sent from my iPad
>> ___
>> 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 draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

I assume you meant that as a reply to me?

The problem is twofold:

1. Printing the value without adornment, or "nil" for nil, is a very
   common thing to want to do and we shouldn't have to write code like
   `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
2. Due to the changes made to IUOs, if you use a IUO in a string
   interpolation, previously it would print as desired (either the value
   or the string `"nil"`) but now it prints as Optional (e.g. with the
   `"Optional(…)"` wrapper).

-Kevin

On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
> Under our proposal you can return to the old semantics of printing
> nil with an explicit optional cast - one which we will offer to
> insert for you.
>
> Otherwise if you actually intend for a default value that value would
> have type Int, not String.  Under the current regime if you want to
> print something custom the for nil the way you've got it now you're
> going to have to go through the reflecting initializer anyway so I
> don't see a problem here.
>
> ~Robert Widmann
>
> 2016/10/03 19:25、Charlie Monroe via swift-evolution  evolut...@swift.org> のメッセージ:
>> I've already suggested this quite some time back and was told that
>> this doesn't need to go through evolution. It's filed here:
>> https://bugs.swift.org/browse/SR-1882
>>
>> Unfortunately, I haven't had time to look into it myself and I'm
>> unlikely to have the time anytime soon...
>>
>>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>>
>>> Hey all,
>>>
>>> Julio Carrettoni, Robert Widmann, and I have been working on a
>>> proposal to mitigate something that's burned us all since Swift 1.
>>> We'd love some feedback!
>>>
>>> It's available here:
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>>>
>>> I've posted the current draft below.
>>>
>>> Thanks,
>>> Harlan Haskins
>>>
>>> Disallow Optionals in String Interpolation Segments


>>>  * Proposal: SE-[1]
>>>  * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert
>>>Widmann[4]
>>>  * Review Manager: TBD
>>>  * Status: Awaiting revie
>>> Introduction
>>> Swift developers frequently use string interpolation as a
>>> convenient, concise syntax for interweaving variable values with
>>> strings. The interpolation machinery, however, has surprising
>>> behavior in one specific case: Optional. If a user puts an
>>> optional value into a string interpolation segment, it will insert
>>> either "Optional("value")" or "nil" in the resulting string. Neither
>>> of these is particularly desirable, so we propose a warning and fix-
>>> it to surface solutions to these potential mistakes.
>>> Swift-evolution thread: Discussion thread topic for that proposal[5]
>>> Motivation
>>> *The Swift Programming Language* defines string interpolation
>>> segments as "a way to construct a new String value from a mix of
>>> constants, variables, literals, and expressions". There is one type
>>> that runs counter to this definition: Optional. The .none case in
>>> particular is used to indicate the absence of a value. Moreover, its
>>> inclusion in interpolation segments leads to the dreaded "nil" in
>>> output that is often fed to UI elements. Even barring that,
>>> interpolating a non-nil optional value yields "Optional("value")", a
>>> result that is not useful even in logged output.
>>> Given that the Optional type is never fit for display to the end
>>> user, and can often be a surprising find in the console, we propose
>>> that requesting an Optional's debug description be an explicit act.
>>> This proposal now requires a warning when using an expression of
>>> Optional type within a string interpolation segment.
>>> Proposed solution
>>> The user will be warned after attempting to use an expression with
>>> type Optional in a string interpolation segment. They will then
>>> be offered a fixit suggesting they explicitly request the
>>> debugDescription of the Optional value instead.
>>> Detailed design
>>> Semantic analysis currently does not do much but guarantee the well-
>>> formedness of expressions in interpolation segments. These are then
>>> fed directly to String.init(stringInterpolationSegment:) and are run
>>> through the runtime reflection system to generate a description.
>>> Semantic analysis will be tweaked to inspect the result of solving
>>> an interpolation segment for an Optional and will offer a fixit in
>>> that case.
>>> Impact on existing code
>>> As this is a warning, code written before this proposal will
>>> continue to compile and run with the same semantics as before.
>>> Authors of code that makes use of this unsafe pattern will be
>>> offered a migration path to the safer, more explicit form.
>>> Alternatives considered


>>>  * A fixit that suggests a default value be inserted would be
>>>entirely appropriate (following the style of the fixit introduced
>>>in SE-0140[6]).


>>>  * Forbidding this pat

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

[Kevin Ballard via swift-evolution]

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 Sadun  wrote:
> >> 
> >> > Indices have a specific, fixed meaning in Swift, which are used to 
> >> > create valid collection
> >> > subscripts. This proposal introduces indexed() to produce a more 
> >> > semantically relevant sequence
> > by
> >
> >> > pairing a collection's indices with its members. While it is trivial to 
> >> > create a solution in Swift,
> >> > the most common developer approach shown here calculates indexes twice:
> >> >
> >> > extension Collection {
> >> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents 
> >> > a
> >> > /// consecutive collection index, and *x* represents an element of
> >> > /// the sequence.
> >> > func indexed() -> Zip2Sequence {
> >> > return zip(indices, self)
> >> > }
> >> > }
> >> 
> >> How does this calculate indices twice?
> >
> > It calculates indices twice for any collection that uses
> > IndexingIterator as its iterator. 
> 
> Yes.  Not in general; just in that particular case.
> 
> > And for collections that doesn't, it still does the moral equivalent,
> > because it's calculating an index offset along with whatever work the
> > Iterator does to calculate the next element.
> 
> Indexing is supposed to be cheap; almost free.  Lazy filtered
> collections are an anomaly.  They're arguably not even legal
> Collections, because advancing an index may not be O(1).  They exist
> because they're useful, but you shouldn't pass them out without
> understanding the consequences.

Using an index is supposed to be cheap/free. Calculating the next index is not 
guaranteed to be so. If you want another example of something that's not lazy, 
try String.CharacterView. Calculating the next index may be arbitrarily complex 
since I can string as many combining marks together as I want, though in 
practice it will be pretty cheap. But even this "pretty cheap" is still work, 
and depending on what I'm doing in the loop, calculating character indexes may 
be a significant fraction of the work performed.

> > As an example, if my collection is `someArray.lazy.filter(…)` then
> > zip(col.indices, col) will run the filter twice over the collection.
> 
> Okay.
> 
> >> > Incrementing an index in some collections can be unnecessarily
> >> > costly. 
> >> 
> >> Seems like it's only *unnecessarily* costly in badly implemented
> >> collections?
> >
> > A collection doesn't have to be badly-implemented to have a
> > non-trivial cost for calculating the next element. 
> > As above, someArray.lazy.filter(…) is a good example of such a
> > collection.
> 
> Its conformance to Collection is quite sketchy.

But it's not the only collection where calculating indexes is non-trivial.

-Kevin Ballard

> >> > In a lazy filtered collection, an index increment is potentially
> >> > O(N). We feel this is better addressed introducing a new function into
> >> > the Standard Library to provide a more efficient design that avoids
> >> > the attractive nuisance of the "obvious" solution.
> >> 
> >> I am generally opposed to adding this.  The usual solution developers
> >> will reach for here is:
> >> 
> >> for i in x.indices {
> >> somethingWith(x[i])
> >> }
> >> 
> >> zip(indices, self) is only suboptimal for lazy filtered sequences, which
> >> should be used with care anyhow (see the note here:
> >> http://swiftdoc.org/v3.0/type/LazyFilterCollection/).
> >
> > It's suboptimal for any collection with a non-trivial index.
> 
> Which should be an exceedingly rare thing.
> 
> >> If you really need a lazy sequence of pairs that's optimal with lazy
> >> filtered sequences, 
> >> 
> >> x.indices.lazy.map { ($0, x[$0]) }
> >> 
> >> is a good solution and pretty easy to write.
> >
> > And yet people will write zip(x.indices, x) instead because it's
> > shorter and not immediately obvious that it may be suboptimal
> > depending on the collection.
> >
> > Why are you opposed to adding this? 
> 
> Mostly because it's additional API complexity, the usefulness appears to
> be marginal, and it's optimizing for what should be a rare corner case
> (collections that don't conform to efficiency expectations).
> 
> I'm not dead-set against adding it, but ATM it doesn't seem like there
> are important use-cases that will benefit substantially from having it.
> Convince me this is addressing a real need, and we'll talk.  In phase 2
> :-).
> 
> > The ability to work around its lack doesn't mean it doesn't have
> > value, and the fact that the simplest workaround is not the best one
> > is I think a good reason to make the easiest solution into the best
> > one (by providing .indexed()). Add to that the fact that a lot of
> > people probably use .enumerated() to produce indexes when working with
> > arrays, and this is

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

[Joe Groff via swift-evolution]

> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
> they’re clearly in the domain of possible values that can be fed to a 
> switch-case.  Exhaustiveness guarantees wellformedness of a program that does 
> happen to go wrong, and makes it much easier to verify the correctness of the 
> flow of control of the containing block because all points from the switch 
> must be covered.  We also don’t have the type-level tools to convince the 
> checker to allow you to remove unreachable cases.  If it’s really a problem 
> that you are writing default cases everywhere, just bailout in a fatal error 
> with a nice description.  It never hurts.

I can see the utility of a `switch!` construct that introduces the 'default: 
fatalError()' on your behalf. No matter how much analysis we do, there are 
always going to be cases with 'where' guards and expr patterns that we can't 
decidably analyze for exhaustiveness, for which runtime safety is the best we 
can offer. (That said, it'd fall squarely in the "sugar" bucket, so while it's 
an interesting idea to explore, it's not immediate Swift 4 Phase 1 material.)

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] replace (if/guard) case = with ~=

[Erica Sadun via swift-evolution]

Resolved: `if case 1...10 = myNumber { ... }` is an abomination.

It confuses inexperience developers. At least those few who are 
aware of its existence. Using the assignment operator for pattern 
matching adds insult to injury. 

I far prefer
`if case .failure(let error) ~= result { ... } `
to
`if case .failure(let error) = result {...}`

Though worthy, this isn't a popular pattern.  A highly unscientific survey of 
gist reveal:

* Gists using "if case": 94
* Gists that could use "if let" instead of "if case": Approximately 94-ish
* Gists using "guard case" (with significant overlap with "if case"): 54
* Gists that could use "guard let" or "guard x != nil" or "guard x == 
.enumeration" instead: About 54-ish
* Standard library: 1 use of "guard case", 5 uses of "if case".

Note:

* I love `guard case`/`if case` for `Result` enumerations
* I  love`for case let x? in [optionals]`. 

I don't expect changing `=` to `~=` would make a huge difference in adoption 
but it would satisfy  my inner code critic. Changing it would be breaking
but as far as I can tell, it wouldn't really break *that* *much* *code*

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
>> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
>> they’re clearly in the domain of possible values that can be fed to a 
>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>> does happen to go wrong, and makes it much easier to verify the correctness 
>> of the flow of control of the containing block because all points from the 
>> switch must be covered.  We also don’t have the type-level tools to convince 
>> the checker to allow you to remove unreachable cases.  If it’s really a 
>> problem that you are writing default cases everywhere, just bailout in a 
>> fatal error with a nice description.  It never hurts.
> 
> I can see the utility of a `switch!` construct that introduces the 'default: 
> fatalError()' on your behalf. No matter how much analysis we do, there are 
> always going to be cases with 'where' guards and expr patterns that we can't 
> decidably analyze for exhaustiveness, for which runtime safety is the best we 
> can offer. (That said, it'd fall squarely in the "sugar" bucket, so while 
> it's an interesting idea to explore, it's not immediate Swift 4 Phase 1 
> material.)

This seems to me like the perfect answer for Swift.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> I assume you meant that as a reply to me?
> 
> The problem is twofold:
> 
> 1. Printing the value without adornment, or "nil" for nil, is a very common 
> thing to want to do and we shouldn't have to write code like 
> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.

My point is before you were unable to do this without the ‘uglyness’ presented 
here anyway [you would have gotten “Optional(“value”)”], so I don’t see the 
point of raising this concern.  If you want the old behavior, just ask for it 
with an explicit cast or `.debugDescription`.

> 2. Due to the changes made to IUOs, if you use a IUO in a string 
> interpolation, previously it would print as desired (either the value or the 
> string `"nil"`) but now it prints as Optional (e.g. with the `"Optional(…)"` 
> wrapper).

IUOs are not in the scope for this proposal, but I get your point.

> 
> -Kevin
> 
> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
>> Under our proposal you can return to the old semantics of printing nil with 
>> an explicit optional cast - one which we will offer to insert for you.
>> 
>> Otherwise if you actually intend for a default value that value would have 
>> type Int, not String.  Under the current regime if you want to print 
>> something custom the for nil the way you've got it now you're going to have 
>> to go through the reflecting initializer anyway so I don't see a problem 
>> here.
>> 
>> ~Robert Widmann
>> 
>> 2016/10/03 19:25、Charlie Monroe via swift-evolution 
>> mailto:swift-evolution@swift.org>> のメッセージ:
>>> I've already suggested this quite some time back and was told that this 
>>> doesn't need to go through evolution. It's filed here: 
>>> https://bugs.swift.org/browse/SR-1882 
>>> 
>>> 
>>> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
>>> to have the time anytime soon...
>>> 
 On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 Hey all,
 
 Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
 mitigate something that's burned us all since Swift 1. We'd love some 
 feedback!
 
 It's available here: 
 https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
 
 
 I've posted the current draft below.
 
 Thanks,
 Harlan Haskins
 
 Disallow Optionals in String Interpolation Segments
 
 Proposal: SE- 
 Authors: Harlan Haskins , Julio 
 Carrettoni , Robert Widmann 
 
 Review Manager: TBD
 Status: Awaiting revie
  
 Introduction
 
 Swift developers frequently use string interpolation as a convenient, 
 concise syntax for interweaving variable values with strings. The 
 interpolation machinery, however, has surprising behavior in one specific 
 case: Optional. If a user puts an optional value into a string 
 interpolation segment, it will insert either "Optional("value")" or "nil" 
 in the resulting string. Neither of these is particularly desirable, so we 
 propose a warning and fix-it to surface solutions to these potential 
 mistakes.
 
 Swift-evolution thread: Discussion thread topic for that proposal 
 
  
 Motivation
 
 The Swift Programming Language defines string interpolation segments as "a 
 way to construct a new String value from a mix of constants, variables, 
 literals, and expressions". There is one type that runs counter to this 
 definition: Optional. The .none case in particular is used to indicate the 
 absence of a value. Moreover, its inclusion in interpolation segments 
 leads to the dreaded "nil" in output that is often fed to UI elements. 
 Even barring that, interpolating a non-nil optional value yields 
 "Optional("value")", a result that is not useful even in logged output.
 
 Given that the Optional type is never fit for display to the end user, and 
 can often be a surprising find in the console, we propose that requesting 
 an Optional's debug description be an explicit act. This proposal now 
 requires a warning when using an expression of Optional type within a 
 string interpolation segment.
 
  
 Proposed
  solution

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

[Kevin Ballard via swift-evolution]

On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>
>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> I assume you meant that as a reply to me?
>>
>> The problem is twofold:
>>
>> 1. Printing the value without adornment, or "nil" for nil, is a
>>very common thing to want to do and we shouldn't have to write
>>code like `\(x.map(String.init(describing:)) ?? "nil")` to
>>accomplish it.
>
> My point is before you were unable to do this without the ‘uglyness’
> presented here anyway [you would have gotten “Optional(“value”)”], so
> I don’t see the point of raising this concern.  If you want the old
> behavior, just ask for it with an explicit cast or
> `.debugDescription`.

This proposal was done because the current behavior of Optionals in
string interpolation isn't very useful for most people. You're proposing
banning it outright (with an escape hatch to recover the current
behavior). I'm saying that, since it isn't very useful for most people,
instead of banning it we could make it useful.

-Kevin

>> 2. Due to the changes made to IUOs, if you use a IUO in a string
>>interpolation, previously it would print as desired (either the
>>value or the string `"nil"`) but now it prints as Optional (e.g.
>>with the `"Optional(…)"` wrapper).
>
> IUOs are not in the scope for this proposal, but I get your point.
>
>>
>> -Kevin
>>
>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-
>> evolution wrote:
>>> Under our proposal you can return to the old semantics of printing
>>> nil with an explicit optional cast - one which we will offer to
>>> insert for you.
>>>
>>> Otherwise if you actually intend for a default value that value
>>> would have type Int, not String.  Under the current regime if you
>>> want to print something custom the for nil the way you've got it now
>>> you're going to have to go through the reflecting initializer anyway
>>> so I don't see a problem here.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/10/03 19:25、Charlie Monroe via swift-evolution >> evolut...@swift.org> のメッセージ:
 I've already suggested this quite some time back and was told that
 this doesn't need to go through evolution. It's filed here:
 https://bugs.swift.org/browse/SR-1882

 Unfortunately, I haven't had time to look into it myself and I'm
 unlikely to have the time anytime soon...

> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution  evolut...@swift.org> wrote:
>
>
> Hey all,
>
> Julio Carrettoni, Robert Widmann, and I have been working on a
> proposal to mitigate something that's burned us all since Swift 1.
> We'd love some feedback!
>
> It's available here:
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>
> I've posted the current draft below.
>
> Thanks,
> Harlan Haskins
>
> Disallow Optionals in String Interpolation Segments


>  * Proposal: SE-[1]
>  * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert
>Widmann[4]
>  * Review Manager: TBD
>  * Status: Awaiting revie
> Introduction
> Swift developers frequently use string interpolation as a
> convenient, concise syntax for interweaving variable values with
> strings. The interpolation machinery, however, has surprising
> behavior in one specific case: Optional. If a user puts an
> optional value into a string interpolation segment, it will insert
> either "Optional("value")" or "nil" in the resulting string.
> Neither of these is particularly desirable, so we propose a
> warning and fix-it to surface solutions to these potential
> mistakes.
> Swift-evolution thread: Discussion thread topic for that
> proposal[5]
> Motivation
> *The Swift Programming Language* defines string interpolation
> segments as "a way to construct a new String value from a mix of
> constants, variables, literals, and expressions". There is one
> type that runs counter to this definition: Optional. The .none
> case in particular is used to indicate the absence of a value.
> Moreover, its inclusion in interpolation segments leads to the
> dreaded "nil" in output that is often fed to UI elements. Even
> barring that, interpolating a non-nil optional value yields
> "Optional("value")", a result that is not useful even in logged
> output.
> Given that the Optional type is never fit for display to the end
> user, and can often be a surprising find in the console, we
> propose that requesting an Optional's debug description be an
> explicit act. This proposal now requires a warning when using an
> expression of Optional type within a string interpolation segment.
> Proposed solution
> The user will be warned after attempting to use an expression with
> type Optional in a string interpolation segment. They will then
> be offered a

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

[Robert Widmann via swift-evolution]

> On Oct 3, 2016, at 9:54 PM, Kevin Ballard  wrote:
> 
> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>> 
>>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I assume you meant that as a reply to me?
>>> 
>>> The problem is twofold:
>>> 
>>> 1. Printing the value without adornment, or "nil" for nil, is a very common 
>>> thing to want to do and we shouldn't have to write code like 
>>> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>> 
>> My point is before you were unable to do this without the ‘uglyness’ 
>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>> don’t see the point of raising this concern.  If you want the old behavior, 
>> just ask for it with an explicit cast or `.debugDescription`.
> 
> This proposal was done because the current behavior of Optionals in string 
> interpolation isn't very useful for most people. You're proposing banning it 
> outright (with an escape hatch to recover the current behavior). I'm saying 
> that, since it isn't very useful for most people, instead of banning it we 
> could make it useful.

Then Optional needs to have a stable and useful `.description`, but I don’t 
think it’s appropriate to have users rely on the output of `debugDescription` 
much less use it in interpolated strings as it is now.  That’s why we wrote 
this proposal.  We are changing no behavior, your programs will still compile 
under this proposal, they will still execute with the same semantics as before, 
you will just get a warning that you cannot and should not depend on the debug 
representation of a type that specifically has a case for “no value here”.  If 
you want to silence that warning you’re gonna have to jump through some hoops - 
hoops that we’ll show you with fixits.

> -Kevin
> 
>>> 2. Due to the changes made to IUOs, if you use a IUO in a string 
>>> interpolation, previously it would print as desired (either the value or 
>>> the string `"nil"`) but now it prints as Optional (e.g. with the 
>>> `"Optional(…)"` wrapper).
>> 
>> IUOs are not in the scope for this proposal, but I get your point.
>> 
>>> 
>>> -Kevin
>>> 
>>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
 Under our proposal you can return to the old semantics of printing nil 
 with an explicit optional cast - one which we will offer to insert for you.
 
 Otherwise if you actually intend for a default value that value would have 
 type Int, not String.  Under the current regime if you want to print 
 something custom the for nil the way you've got it now you're going to 
 have to go through the reflecting initializer anyway so I don't see a 
 problem here.
 
 ~Robert Widmann
 
 2016/10/03 19:25、Charlie Monroe via swift-evolution 
 mailto:swift-evolution@swift.org>> のメッセージ:
> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882 
> 
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
> to have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>> 
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE- 
>> 
>> Authors: Harlan Haskins , Julio 
>> Carrettoni , Robert Widmann 
>> 
>> Review Manager: TBD
>> Status: Awaiting revie
>>  
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warning and fix-it to surface solutions to 
>> these potential mi

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

[Robert Widmann via swift-evolution]

Forgive me for mixing terminology from before stating “If you want the old 
behavior” and the like.  What I meant is “If you want to silence the warning”.  
I should point out that it is just that: a warning.  We specifically mention 
that we didn’t spring for a hard error because that would make this a 
source-breaking proposal and we realize that it is useful to be able to quickly 
print an optional to test something.  But at the end of the day you should 
think about the representation of data flowing through your program and be 
explicit about whether you want the debug interpretation of an optional value 
or whether you intended - as we believe is true of the majority of cases - to 
provide a default non-optional value.

> On Oct 3, 2016, at 9:54 PM, Kevin Ballard  wrote:
> 
> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>> 
>>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I assume you meant that as a reply to me?
>>> 
>>> The problem is twofold:
>>> 
>>> 1. Printing the value without adornment, or "nil" for nil, is a very common 
>>> thing to want to do and we shouldn't have to write code like 
>>> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>> 
>> My point is before you were unable to do this without the ‘uglyness’ 
>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>> don’t see the point of raising this concern.  If you want the old behavior, 
>> just ask for it with an explicit cast or `.debugDescription`.
> 
> This proposal was done because the current behavior of Optionals in string 
> interpolation isn't very useful for most people. You're proposing banning it 
> outright (with an escape hatch to recover the current behavior). I'm saying 
> that, since it isn't very useful for most people, instead of banning it we 
> could make it useful.
> 
> -Kevin
> 
>>> 2. Due to the changes made to IUOs, if you use a IUO in a string 
>>> interpolation, previously it would print as desired (either the value or 
>>> the string `"nil"`) but now it prints as Optional (e.g. with the 
>>> `"Optional(…)"` wrapper).
>> 
>> IUOs are not in the scope for this proposal, but I get your point.
>> 
>>> 
>>> -Kevin
>>> 
>>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
 Under our proposal you can return to the old semantics of printing nil 
 with an explicit optional cast - one which we will offer to insert for you.
 
 Otherwise if you actually intend for a default value that value would have 
 type Int, not String.  Under the current regime if you want to print 
 something custom the for nil the way you've got it now you're going to 
 have to go through the reflecting initializer anyway so I don't see a 
 problem here.
 
 ~Robert Widmann
 
 2016/10/03 19:25、Charlie Monroe via swift-evolution 
 mailto:swift-evolution@swift.org>> のメッセージ:
> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882 
> 
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
> to have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>> 
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE- 
>> 
>> Authors: Harlan Haskins , Julio 
>> Carrettoni , Robert Widmann 
>> 
>> Review Manager: TBD
>> Status: Awaiting revie
>>  
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warnin

Re: [swift-evolution] [pitch] replace (if/guard) case = with ~=

[Nevin Brackett-Rozinsky via swift-evolution]

While we’re on the subject, has there been any discussion about adding a
pattern matching operator with the polarity reversed?

To me at least it seems far more natural to write, eg., “case x =~
somePattern” and to read it as “x matches somePattern” rather than the
status quo “somePattern matches x”.

Nevin



On Mon, Oct 3, 2016 at 9:31 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> *Resolved*: `if case 1...10 = myNumber { ... }` is an abomination.
>
> It confuses inexperience developers. At least those few who are
> aware of its existence. Using the assignment operator for pattern
> matching adds insult to injury.
>
> I far prefer
> `if case .failure(let error) ~= result { ... } `
> to
> `if case .failure(let error) = result {...}`
>
> Though worthy, this isn't a popular pattern.  A highly unscientific survey
> of
> gist reveal:
>
> * Gists using "if case": 94
> * Gists that could use "if let" instead of "if case": Approximately 94-ish
> * Gists using "guard case" (with significant overlap with "if case"): 54
> * Gists that could use "guard let" or "guard x != nil" or "guard x ==
> .enumeration" instead: About 54-ish
> * Standard library: 1 use of "guard case", 5 uses of "if case".
>
> *Note*:
>
> * I love `guard case`/`if case` for `Result` enumerations
> * I  love`for case let x? in [optionals]`.
>
> I don't expect changing `=` to `~=` would make a huge difference in
> adoption
> but it would satisfy  my inner code critic. Changing it would be breaking
> but as far as I can tell, it wouldn't really break *that* *much* *code*
>
> -- E
>
>
>
> ___
> 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] [pitch] replace (if/guard) case = with ~=

[Xiaodi Wu via swift-evolution]

On Mon, Oct 3, 2016 at 9:31 PM, Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> While we’re on the subject, has there been any discussion about adding a
> pattern matching operator with the polarity reversed?
>
> To me at least it seems far more natural to write, eg., “case x =~
> somePattern” and to read it as “x matches somePattern” rather than the
> status quo “somePattern matches x”.
>

There has. My memory is foggy now, but I do believe this was one of those
things about which the core team chimed in to say that they had once
seriously considered or even implemented it and then backed it out.


Nevin
>
>
>
> On Mon, Oct 3, 2016 at 9:31 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> *Resolved*: `if case 1...10 = myNumber { ... }` is an abomination.
>>
>> It confuses inexperience developers. At least those few who are
>> aware of its existence. Using the assignment operator for pattern
>> matching adds insult to injury.
>>
>> I far prefer
>> `if case .failure(let error) ~= result { ... } `
>> to
>> `if case .failure(let error) = result {...}`
>>
>> Though worthy, this isn't a popular pattern.  A highly unscientific
>> survey of
>> gist reveal:
>>
>> * Gists using "if case": 94
>> * Gists that could use "if let" instead of "if case": Approximately 94-ish
>> * Gists using "guard case" (with significant overlap with "if case"): 54
>> * Gists that could use "guard let" or "guard x != nil" or "guard x ==
>> .enumeration" instead: About 54-ish
>> * Standard library: 1 use of "guard case", 5 uses of "if case".
>>
>> *Note*:
>>
>> * I love `guard case`/`if case` for `Result` enumerations
>> * I  love`for case let x? in [optionals]`.
>>
>> I don't expect changing `=` to `~=` would make a huge difference in
>> adoption
>> but it would satisfy  my inner code critic. Changing it would be breaking
>> but as far as I can tell, it wouldn't really break *that* *much* *code*
>>
>> -- E
>>
>>
>>
>> ___
>> 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] [Pitch] Can we make `default` on switches optional?

[Goffredo Marocchi via swift-evolution]

The best answer is always "that would be an ecumenical matter...". It works 
here too ;).

Sent from my iPhone

> On 4 Oct 2016, at 03:44, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> 
>>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
>>> be able to ignore cases that “can’t happen” (so say we, writer of bugs) 
>>> when they’re clearly in the domain of possible values that can be fed to a 
>>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>>> does happen to go wrong, and makes it much easier to verify the correctness 
>>> of the flow of control of the containing block because all points from the 
>>> switch must be covered.  We also don’t have the type-level tools to 
>>> convince the checker to allow you to remove unreachable cases.  If it’s 
>>> really a problem that you are writing default cases everywhere, just 
>>> bailout in a fatal error with a nice description.  It never hurts.
>> 
>> I can see the utility of a `switch!` construct that introduces the 'default: 
>> fatalError()' on your behalf. No matter how much analysis we do, there are 
>> always going to be cases with 'where' guards and expr patterns that we can't 
>> decidably analyze for exhaustiveness, for which runtime safety is the best 
>> we can offer. (That said, it'd fall squarely in the "sugar" bucket, so while 
>> it's an interesting idea to explore, it's not immediate Swift 4 Phase 1 
>> material.)
> 
> This seems to me like the perfect answer for Swift.
> 
> ___
> 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 draft] Disallow Optionals in String Interpolation Segments

[Charlie Monroe via swift-evolution]

> On Oct 4, 2016, at 3:57 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 3, 2016, at 9:54 PM, Kevin Ballard > > wrote:
>> 
>> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>>> 
 On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I assume you meant that as a reply to me?
 
 The problem is twofold:
 
 1. Printing the value without adornment, or "nil" for nil, is a very 
 common thing to want to do and we shouldn't have to write code like 
 `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>>> 
>>> My point is before you were unable to do this without the ‘uglyness’ 
>>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>>> don’t see the point of raising this concern.  If you want the old behavior, 
>>> just ask for it with an explicit cast or `.debugDescription`.
>> 
>> This proposal was done because the current behavior of Optionals in string 
>> interpolation isn't very useful for most people. You're proposing banning it 
>> outright (with an escape hatch to recover the current behavior). I'm saying 
>> that, since it isn't very useful for most people, instead of banning it we 
>> could make it useful.
> 
> Then Optional needs to have a stable and useful `.description`, but I don’t 
> think it’s appropriate to have users rely on the output of `debugDescription` 
> much less use it in interpolated strings as it is now.  That’s why we wrote 
> this proposal.  We are changing no behavior, your programs will still compile 
> under this proposal, they will still execute with the same semantics as 
> before, you will just get a warning that you cannot and should not depend on 
> the debug representation of a type that specifically has a case for “no value 
> here”.  If you want to silence that warning you’re gonna have to jump through 
> some hoops - hoops that we’ll show you with fixits.

There were these concerns:

- the documentation explicitly discourages people to call description or 
debugDescription from within the code. So my original suggestion to make the 
fixit simply call debugDescription was met with resistance since this is 
discouraged. I am not sure about the reasoning for this though.

- some people did find the Optional(value) wrap useful and changing it could be 
viewed on as breaking change, though cases where the user may be testing a 
string for Optional seems rare at best. But again, there were voices that were 
loudly against.

- suggestion by Chris Lattner was to silence the warning either by:
- wrapping the expression in extra parentheses
- adding ?? and default value

Personally, I do not like this suggestion since it makes the code readability 
low due to the fact that the expression is within a string and thus formatting 
options that would help you improve readability are limited. 

I've suggested adding two methods to Optional:

- func descriptionWithDefaultValue(_ value: String = "nil") which while more 
descriptive isn't discouraged from being called directly and allows you to 
specify nil value (I have use cases for empty string, etc.)

- var detailedDescription: String - simply returns current implementation of 
debugDescription


My extension of Optional:

https://github.com/charlieMonroe/XUCore/blob/master/XUCore/additions/OptionalAdditions.swift
 


Original proposal:

https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385 



> 
>> -Kevin
>> 
 2. Due to the changes made to IUOs, if you use a IUO in a string 
 interpolation, previously it would print as desired (either the value or 
 the string `"nil"`) but now it prints as Optional (e.g. with the 
 `"Optional(…)"` wrapper).
>>> 
>>> IUOs are not in the scope for this proposal, but I get your point.
>>> 
 
 -Kevin
 
 On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
> Under our proposal you can return to the old semantics of printing nil 
> with an explicit optional cast - one which we will offer to insert for 
> you.
> 
> Otherwise if you actually intend for a default value that value would 
> have type Int, not String.  Under the current regime if you want to print 
> something custom the for nil the way you've got it now you're going to 
> have to go through the reflecting initializer anyway so I don't see a 
> problem here.
> 
> ~Robert Widmann
> 
> 2016/10/03 19:25、Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> のメッセージ:
>> I've already suggested this quite some time back and was told that this 
>> doesn't need to go through evolution. It's filed here: 
>> https://bugs.swift.org/browse/SR-1882 

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

[Rien via swift-evolution]

+1.

I have several cases where I cannot use enums, this proposal would solve that.


> On 03 Oct 2016, at 21:53, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I made a typo in my previous post.
> 
> Bikeshdding with correct types:
> 
> struct A : Hashable { /* implement everything */ }
> 
> // Variant 1:
> enum Test : A {
> case something = A(value: "something")
> case nothing = A(value: "nothing")
> }
> 
> // Variant 2:
> 
> protocol SomeFancyName : RawRepresentable { … }
> 
> struct Test : SomeFancyName {
>   
> let rawValue: A
> init?(rawValue: A) {
> // Implement + reject unwanted `A`s   
> }
>   
> static let something = Test(rawValue: A(value: "something"))
> static let nothing = Test(rawValue: A(value: "nothing"))
> }
> 
> let value = Test.something
> 
> switch value {
>   
> case .something:
> // handle
>   
> case .nothing:
> // handle
>   
> // Because of `SomeFancyName` the switch can use enum-like pattern matching + 
> does not need the `default` case when all cases are present
> }
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. Oktober 2016 um 21:50:07, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> 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 Name : String { … }).
>> 
>> Sometimes this is not enough for my use-case and I wish I could feed my 
>> enums with other Hashable types!
>> 
>> As a workaround I can create a custom struct or even a class and conform it 
>> to RawRepresentable and fake an enum with some static variables (similar to 
>> what is done with OptionSet types).
>> 
>> The problem there is that I cannot use the same switch pattern matching like 
>> with enums. I’d wish either enums could accept Hashable types (maybe with 
>> some restriction) or the existence on a protocol to build custom enum-like 
>> types with strucs/classes and use the same switch pattern matching.
>> 
>> struct A : Hashable { /* implement everything */ }
>> 
>> // Variant 1:
>> enum Test : A {
>> case something = A(rawValue: A(value: "something"))
>> case nothing = A(rawValue: A(value: "nothing"))   
>> }
>> 
>> // Variant 2:
>> 
>> protocol SomeFancyName : RawRepresentable { … }
>> 
>> struct Test : SomeFancyName {
>>   
>> let rawValue: A
>> init?(rawValue: A) {
>> // Implement + reject unwanted `A`s   
>> }
>>   
>> static let something = A(rawValue: A(value: "something"))
>> static let nothing = A(rawValue: A(value: "nothing"))
>> }
>> 
>> let value = Test.something
>> 
>> switch value {
>>   
>> case .something:
>> // handle
>>   
>> case .nothing:
>> // handle
>>   
>> // Because of `SomeFancyName` the switch can use enum-like pattern matching 
>> + does not need the `default` case when all cases are present
>> }
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
> 
> ___
> 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