Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Dave DeLong via swift-evolution]

> On Jan 1, 2018, at 10:47 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> I agree that we need a solution to the problem described.  I also agree that 
>> non-exhaustive is most in keeping with the overall design of Swift at module 
>> boundaries.  However, I believe this proposal should be modified before 
>> being accepted
> 
> Thanks for writing this up - you’ve explained a common concern in an 
> interesting way:
> 
>> This is likely to be a relatively rare need mostly encountered by 3rd party 
>> libraries but it will happen.  When it does happen it would be really 
>> unfortunate to be forced to use a `default` clause rather than something 
>> like a `future` clause which will produce an error when compiled against an 
>> SDK where the enum includes cases that are not covered.  I can imagine cases 
>> where this catch-all case would need to do something other than abort the 
>> program so I do not like the `switch!` suggestion that has been discussed.  
>> The programmer should still be responsible for determining the behavior of 
>> unknown cases.
> ..
>> While library authors have a legitimate need to reserve the right to 
>> introduce new cases for some enums this need can be met without taking away 
>> a useful tool for generating static compiler errors when code does not align 
>> with intent (in this case, the intent being to cover all known cases).  
>> Switch statements working with these kinds of enums should be required to 
>> cover unknown cases but should be able to do so while still being statically 
>> checked with regards to known cases.  
> 
> I think that this could be the crux of some major confusion, the root of 
> which is the difference between source packages and binary packages that are 
> updated outside your control (e.g. the OS, or a dynamic library that is 
> updated independently of your app like a 3rd party plugin).  Consider:
> 
> 1) When dealing with independently updated binary packages, your code *has* 
> to implement some behavior for unexpected cases if the enum is 
> non-exhaustive.  It isn’t acceptable to not handle that case, and it isn’t 
> acceptable to abort because then your app will start crashing when a new OS 
> comes out. You have to build some sort of fallback into your app.
> 
> 2) When dealing with a source package that contributes to your app (e.g. 
> through SwiftPM), *YOU* control when you update that package, and therefore 
> it is entirely reasonable to exhaustively handle enums even if that package 
> owner didn’t “intend” for them to be exhaustive.  When *you* chose to update 
> the package, you get the “unhandled case” error, and you have maximal 
> “knowability” about the package’s behavior.
> 
> 
> It seems that your concern stems from the fact that the feature as proposed 
> is aligned around module boundaries, and therefore overly punishes source 
> packages like #2.  I hope you agree that in case #1, that the feature as 
> proposed is the right and only thing we can do: you really do have to handle 
> unknown future cases somehow.
> 
> If I’m getting this right, then maybe there is a variant of the proposal that 
> ties the error/warning behavior to whether or not a module is a source module 
> vs a binary module.  The problem with that right now is that we have no 
> infrastructure in the language to know this…

YES . This is the conclusion I’ve been coming to as well as I’ve been mulling 
it over.

Exhaustiveness is *only* an issue for modules that are updated independently of 
my app (ie, via an OS or other externally-linked library changing). Modules 
that are shipped with my app are unaffected with this.

I’d really love it if the build system could know that “this module is bundled 
with your app and therefore switches on its enums don't need a default case but 
this other module isn’t bundled with the app, and so therefore switches on its 
enums DO needs a default case”.

Personally, I’m falling on the side of “all enums from external modules are 
non-exhaustive”, but I recognize there are some cases where that’s semantically 
incorrect (Optional, for one; NSComparisonResult for another). In those 
cases, I think I’d prefer to have an attribute on the enum that is overly long 
and scary in order to emphasize that, once shipped, this enum must never change 
again. Something like:

@mustNeverEverEverChangeInAFutureRelease public enum Optional {
case none
case some(T)
}

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

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Chris Lattner via swift-evolution]

> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I agree that we need a solution to the problem described.  I also agree that 
> non-exhaustive is most in keeping with the overall design of Swift at module 
> boundaries.  However, I believe this proposal should be modified before being 
> accepted

Thanks for writing this up - you’ve explained a common concern in an 
interesting way:

> This is likely to be a relatively rare need mostly encountered by 3rd party 
> libraries but it will happen.  When it does happen it would be really 
> unfortunate to be forced to use a `default` clause rather than something like 
> a `future` clause which will produce an error when compiled against an SDK 
> where the enum includes cases that are not covered.  I can imagine cases 
> where this catch-all case would need to do something other than abort the 
> program so I do not like the `switch!` suggestion that has been discussed.  
> The programmer should still be responsible for determining the behavior of 
> unknown cases.
..
> While library authors have a legitimate need to reserve the right to 
> introduce new cases for some enums this need can be met without taking away a 
> useful tool for generating static compiler errors when code does not align 
> with intent (in this case, the intent being to cover all known cases).  
> Switch statements working with these kinds of enums should be required to 
> cover unknown cases but should be able to do so while still being statically 
> checked with regards to known cases.  

I think that this could be the crux of some major confusion, the root of which 
is the difference between source packages and binary packages that are updated 
outside your control (e.g. the OS, or a dynamic library that is updated 
independently of your app like a 3rd party plugin).  Consider:

1) When dealing with independently updated binary packages, your code *has* to 
implement some behavior for unexpected cases if the enum is non-exhaustive.  It 
isn’t acceptable to not handle that case, and it isn’t acceptable to abort 
because then your app will start crashing when a new OS comes out. You have to 
build some sort of fallback into your app.

2) When dealing with a source package that contributes to your app (e.g. 
through SwiftPM), *YOU* control when you update that package, and therefore it 
is entirely reasonable to exhaustively handle enums even if that package owner 
didn’t “intend” for them to be exhaustive.  When *you* chose to update the 
package, you get the “unhandled case” error, and you have maximal “knowability” 
about the package’s behavior.


It seems that your concern stems from the fact that the feature as proposed is 
aligned around module boundaries, and therefore overly punishes source packages 
like #2.  I hope you agree that in case #1, that the feature as proposed is the 
right and only thing we can do: you really do have to handle unknown future 
cases somehow.

If I’m getting this right, then maybe there is a variant of the proposal that 
ties the error/warning behavior to whether or not a module is a source module 
vs a binary module.  The problem with that right now is that we have no 
infrastructure in the language to know this…

-Chris




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

Re: [swift-evolution] why cant you initialize BinaryFloatingPoint from BinaryInteger?

[Xiaodi Wu via swift-evolution]

This would be a good addition to the BinaryFloatingPoint protocol. It's not
difficult to implement; it's not present (afaict) simply because
BinaryFloatingPoint was designed before BinaryInteger existed.


On Mon, Jan 1, 2018 at 3:58 PM, Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> title says it all,, this is kind of annoying when writing some generic
> FloatingPoint code where both the integral and floating parameters are
> unfixed.
>
> ___
> 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] why cant you initialize BinaryFloatingPoint from BinaryInteger?

[Kelvin Ma via swift-evolution]

title says it all,, this is kind of annoying when writing some generic
FloatingPoint code where both the integral and floating parameters are
unfixed.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Happy new year Swift community.

[Kelvin Ma via swift-evolution]

Happy new year from klossyland!

On Mon, Jan 1, 2018 at 11:23 AM, Georgios Moschovitis via swift-users <
swift-us...@swift.org> wrote:

> Happy new year! Greetings from Cyprus :)
>
> George.
>
> On 1 Jan 2018, at 1:42 AM, Adrian Zubarev via swift-users <
> swift-us...@swift.org> wrote:
>
> Well some of you guys have to wait a little longer, but I can already wish
> everyone a happy new year from Germany. 
>
> --
> Adrian Zubarev
> Sent with Airmail
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Happy new year Swift community.

[Georgios Moschovitis via swift-evolution]

Happy new year! Greetings from Cyprus :)

George.

> On 1 Jan 2018, at 1:42 AM, Adrian Zubarev via swift-users 
>  wrote:
> 
> Well some of you guys have to wait a little longer, but I can already wish 
> everyone a happy new year from Germany.  
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-evolution] Happy new year Swift community.

[Jonathan Hull via swift-evolution]

Happy New Year!

> On Dec 31, 2017, at 6:01 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Happy new year everybody :)!
> 
> Sent from my iPhone
> 
> On 31 Dec 2017, at 23:43, David Hart via swift-evolution 
> > wrote:
> 
>> Thank you very much and happy new Swift year to everybody.
>> 
>> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>>> Well some of you guys have to wait a little longer, but I can already wish 
>>> everyone a happy new year from Germany.  
>>> 
>>> -- 
>>> 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