Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution 
>  a écrit :
> 
> 
>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution 
>> > a écrit :
>> 
>> The ulterior question of whether preserving “DictionaryLiteral” is 
>> worthwhile, is apparently out of scope. Personally, I have a hard time 
>> imagining a compelling use-case outside of the standard library, and I doubt 
>> it’s being used “in the wild” (I checked several projects in the 
>> source-compatibility suite and found zero occurrences).
> 
> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
> DictionaryLiteral in order to build database rows (which may have duplicated 
> column names, and whose column ordering is important). This is mostly useful 
> for tests:
> 
> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
> XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> Gwendal

Chris Lattner's wrote:

> why is maintaining duplicate keys a feature?

> Since it is immutable, why not sort the keys in the initializer, allowing an 
> efficient binary search to look up values?

I really wish both duplicated keys and key ordering would be preserved, since 
both are needed for the above sample code.

Should those features be lost, the sky wouldn't fall, that's sure. But we'd 
have to write something much less easy to wrote and read:

XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])

Gwendal

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

Nate

> On Jan 9, 2018, at 12:12 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> There exists in the standard library a type `DictionaryLiteral` that 
>> deserves naming re-consideration before we declare ABI Stability, because 
>> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> key-based lookup of values) nor a Literal. 
>> 
>> Instead, it’s just an immutable collection of key-value pairs you can create 
>> _from_ a literal.
> 
> Wow.  This is really gross, I didn’t know it existed :-)
> 
> Random question for you.  DictionaryLiteral has this doc comment:
> 
> /// You initialize a `DictionaryLiteral` instance using a Swift dictionary
> /// literal. Besides maintaining the order of the original dictionary literal,
> /// `DictionaryLiteral` also allows duplicates keys. For example:
> 
> why is maintaining duplicate keys a feature?
> 
> 
> It also has this one:
> 
> /// Some operations that are efficient on a dictionary are slower when using
> /// `DictionaryLiteral`. In particular, to find the value matching a key, you
> /// must search through every element of the collection. The call to
> /// `index(where:)` in the following example must traverse the whole
> /// collection to find the element that matches the predicate:
> 
> Since it is immutable, why not sort the keys in the initializer, allowing an 
> efficient binary search to look up values?
> 
> 
>> I’m canvassing for opinions on what it ought to be called.  Some suggestions 
>> so far:
>> 
>> - `AssociationCollection`: Following the term of art from some other 
>> languages. Slightly obscure-sounding to developers not already familiar. 
>> Also “association” and “associative” are confusingly similar, which brings 
>> back the is-this-a-dictionary problem.
>> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
>> different context in Cocoa.
>> - `PairCollection`: “Pair” is kinda nondescript.
>> - Do nothing. It’s not so bad.
>> 
>> The old name can live on indefinitely via a typealias (which has no ABI 
>> consequences, so could be retired at a later date once everyone has had 
>> plenty of time to address the deprecation warnings). Removing it as not 
>> carrying its weight (and instead using `[(Key,Value)]`, which is basically 
>> what it’s a wrapper for) is probably off the table for source stability 
>> reasons.
> 
> I’m not familiar with this type at all, so I apologize for the dumb question 
> but… why was this added in the first place?  If it is the wrong thing, why 
> not just deprecate it in Swift 5 and remove it in a future release?  That 
> avoids it being an ABI concern, because we could make it be force inlined 
> into any client code.

According to now-gone doc comments, it's intended to be used when providing the 
children for a custom mirror (that's the only API I know of that uses the 
type). The order of elements there is important, but given how scarcely used 
the type is, an array of tuples might be a reasonable (though source-breaking) 
substitute. 

> Finally, is anyone actually using this type?

In the standard library, we have this Mirror initializer: 
https://developer.apple.com/documentation/swift/mirror/1540408-init. If anyone 
is customizing their type's mirror, it's a good bet that they're calling that 
init and passing a literal that would break if the argument changed to an 
array. The translation should be mechanical, so maybe it could be a migrator 
fix? (I don't know enough about how that works to know.)

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution 
>  a écrit :
> 
> The ulterior question of whether preserving “DictionaryLiteral” is 
> worthwhile, is apparently out of scope. Personally, I have a hard time 
> imagining a compelling use-case outside of the standard library, and I doubt 
> it’s being used “in the wild” (I checked several projects in the 
> source-compatibility suite and found zero occurrences).

DictionaryLiteral is worthwhile. The SQLite library GRDB uses DictionaryLiteral 
in order to build database rows (which may have duplicated column names, and 
whose column ordering is important). This is mostly useful for tests:

let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
XCTAssertEqual(row, ["a": 1, "a": 2])

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

Re: [swift-evolution] DynamicMemberLookup proposal: status update

[Chris Lattner via swift-evolution]

Yes indeed!  He and I have been exchanging emails :-)

-Chris


> On Jan 5, 2018, at 5:20 AM, Ben Rimmington  wrote:
> 
> Have you seen John Holdsworth's experiments?
> 
> 
> -- Ben
> 
>> On 4 Jan 2018, at 20:52, Chris Lattner wrote:
>> 
>> Hi everyone,
>> 
>> With the holidays and many other things behind us, the core team had a 
>> chance to talk about python interop + the dynamic member lookup proposal 
>> recently.
>> 
>> Here’s where things stand: we specifically discussed whether a 
>> counter-proposal of using “automatically generated wrappers” or “foreign 
>> classes” to solve the problem would be better.  After discussion, the 
>> conclusion is no: the best approach appears to be 
>> DynamicMemberLookup/DynamicCallable or something similar in spirit to them.  
>> As such, I’ll be dusting off the proposal and we’ll eventually run it.
>> 
>> For transparency, I’m attaching the analysis below of what a wrapper 
>> facility could look like, and why it doesn’t work very well for Python 
>> interop.  I appologize in advance that this is sort of train-of-thought and 
>> not a well written doc. 
>> 
>> That said, it would be really great to get tighter integration between Swift 
>> and SwiftPM for other purposes!  I don’t have time to push this forward in 
>> the short term though, but if someone was interested in pushing it forward, 
>> many people would love to see it discussed seriously.
>> 
>> -Chris
> 

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

[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

The mega-thread about SE-0192 is a bit large, and I’d like to talk about one 
specific point.  In the review conversation, there has been significant 
objection to the idea of requiring a ‘default’ for switches over enums that are 
non-exhaustive.  

This whole discussion is happening because the ABI stability work is 
introducing a new concept to enums - invisible members/inhabitants (and making 
them reasonably prominent).  A closely related feature is that may come up in 
the future is "private cases”.  Private cases are orthogonal to API evolution 
and may even occur on one that is defined to be exhaustive.

Private cases and non-exhaustive enums affect the enum in the same way: they 
say that the enum can have values that a client does not know about.  Swift 
requires switches to process *all* of the dynamically possible values, which is 
why the original proposal started out with the simplest possible solution: just 
require ‘default' when processing the cases.


The problems with “unknown case:”

The popular solution to this probably is currently being pitched as a change to 
the proposal (https://github.com/apple/swift-evolution/pull/777) which 
introduces a new concept “unknown case” as a near-alias for ‘default’:
https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case

In short, I think this is the wrong way to solve the problem.  I have several 
concerns with this:

1) Unlike in C, switch is Swift is a general pattern matching facility - not a 
way of processing integers.  It supports recursive patterns and values, and 
enums are not necessarily at the top-level of the pattern.   
https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a 
document from early evolution of Swift but contains a good general introduction 
to this.

2) Swift also has other facilities for pattern matching, including ‘if case’.  
Making switch inconsistent with them is not great.

3) As pitched, “unknown case” will match *known* cases too, which is (in my 
opinion :-) oxymoronic.

4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier on 
case) because case *requires* a pattern.  A better spelling would be “unknown 
default:” which is closer to the semantic provided anyway.

5) It is entirely reasonable (though rare in practice) to want to handle 
default and unknown cases in the same switch.


For all the above reasons, ‘unknown case:' becomes a weird wart put on the side 
of switch/case, not something that fits in naturally with the rest of Swift.


Alternative proposal:

Instead of introducing a new modifier on case/switch, lets just introduce a new 
pattern matching operator that *matches unknown cases*, called “#unknown” or 
“.#unknown” or something (I’m not wed to the syntax, better suggestions welcome 
:).

In the simple case most people are talking about, instead of writing “unknown 
case:” you’d write “case #unknown:” which isn’t much different.  The nice thing 
about this is that #unknown slots directly into our pattern matching system.  
Here is a weird example:

switch someIntEnumTuple {
case (1, .X):   … matches one combination of int and tuple...
case (2, .Y):   … matches another combination of int and tuple...
case (_, #unknown): …  matches any int and any unknown enum case ...
case default:  … matches anything ...
}

Furthermore, if you have a switch that enumerates all of the known cases and 
use #unknown, then it falls out of the model that new cases (e.g. due to an SDK 
upgrade or an updated source package) produces the existing build error.  As 
with the original proposal, you can always choose to use “default:” instead of 
“case #unknown:” if you don’t like that behavior.

Of course, if you have an exhaustive enum (e.g. one defined in your own module 
or explicitly marked as such) then #unknown matches nothing, so we should warn 
about it being pointless.


This addresses my concerns above:

1) This fits into patterns in recursive positions, and slots directly into the 
existing grammar for patterns.  It would be a very simple extension to the 
compiler instead of a special case added to switch/case.

2) Because it slots into the pattern grammar, it works directly with 'if case’ 
and the other pattern matching stuff.

3) Doesn’t match known cases.

4) Doesn’t change the case grammar, it just adds a new pattern terminal 
production.

5) Allows weird cases like the example above.


All that said, the #unknown spelling isn’t great, but I’m sure we can find 
something else nice.

Thoughts?

-Chris


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution 
>  wrote:
> There exists in the standard library a type `DictionaryLiteral` that deserves 
> naming re-consideration before we declare ABI Stability, because it’s 
> confusingly misnamed, being neither a Dictionary (it doesn’t provide 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.

Wow.  This is really gross, I didn’t know it existed :-)

Random question for you.  DictionaryLiteral has this doc comment:

/// You initialize a `DictionaryLiteral` instance using a Swift dictionary
/// literal. Besides maintaining the order of the original dictionary literal,
/// `DictionaryLiteral` also allows duplicates keys. For example:

why is maintaining duplicate keys a feature?


It also has this one:

/// Some operations that are efficient on a dictionary are slower when using
/// `DictionaryLiteral`. In particular, to find the value matching a key, you
/// must search through every element of the collection. The call to
/// `index(where:)` in the following example must traverse the whole
/// collection to find the element that matches the predicate:

Since it is immutable, why not sort the keys in the initializer, allowing an 
efficient binary search to look up values?


> I’m canvassing for opinions on what it ought to be called.  Some suggestions 
> so far:
> 
> - `AssociationCollection`: Following the term of art from some other 
> languages. Slightly obscure-sounding to developers not already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> The old name can live on indefinitely via a typealias (which has no ABI 
> consequences, so could be retired at a later date once everyone has had 
> plenty of time to address the deprecation warnings). Removing it as not 
> carrying its weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.

I’m not familiar with this type at all, so I apologize for the dumb question 
but… why was this added in the first place?  If it is the wrong thing, why not 
just deprecate it in Swift 5 and remove it in a future release?  That avoids it 
being an ABI concern, because we could make it be force inlined into any client 
code.

Finally, is anyone actually using this type?

-Chris



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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

On Tue, Jan 9, 2018 at 00:40 Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Thank you for the clarification. It occurred to me in the shower that
>> this might be the case, and that I was entirely mistaken as to what we were
>> talking about.
>>
>> Yes, then, I wholeheartedly agree on this point. Out of curiosity, why
>> are there source stability issues to 'typealias DictionaryLiteral> Value> = [(Key, Value)]'?
>
>
> Because at the point of use, “DictionaryLiteral” is instantiated with an
> actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t
> available for an array of key-value pairs.
>

Why do we need available syntax? Sure, conformance of [(Key, Value)] to
ExpressibleByDictionaryLiteral can't be written in Swift, but we could make
this a built-in conformance. Literals are magical in many ways no matter
what.

As near as I can tell, the convenience of that spelling is the entire
> *raison-d’être* for “DictionaryLiteral” in the first place.
>
> The ulterior question of whether preserving “DictionaryLiteral” is
> worthwhile, is apparently out of scope. Personally, I have a hard time
> imagining a compelling use-case outside of the standard library, and I
> doubt it’s being used “in the wild” (I checked several projects in the
> source-compatibility suite and found zero occurrences).
>

I have seen examples where its use is encouraged, and I see no reason to
address this "ulterior question."

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nevin Brackett-Rozinsky via swift-evolution]

On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Thank you for the clarification. It occurred to me in the shower that this
> might be the case, and that I was entirely mistaken as to what we were
> talking about.
>
> Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are
> there source stability issues to 'typealias DictionaryLiteral =
> [(Key, Value)]'?


Because at the point of use, “DictionaryLiteral” is instantiated with an
actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t
available for an array of key-value pairs. As near as I can tell, the
convenience of that spelling is the entire *raison-d’être* for
“DictionaryLiteral” in the first place.

The ulterior question of whether preserving “DictionaryLiteral” is
worthwhile, is apparently out of scope. Personally, I have a hard time
imagining a compelling use-case outside of the standard library, and I
doubt it’s being used “in the wild” (I checked several projects in the
source-compatibility suite and found zero occurrences).

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

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Cheyo Jimenez via swift-evolution]

> What is your evaluation of the proposal?
+1
How does this work with public non exhaustive enums?

Can we have a version of this that is compile time only? This would be very 
helpful specially if non exhaustive enums make it into the language. Perhaps 
also having compile time allCases could also gets us closer to objc enum 
support. 

I much rather take the extra copy of all the cases in my binary than having 
surprising results during runtime (new cases or removed cases).

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes
> Does this proposal fit well with the feel and direction of Swift?
Yes
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
N/a
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed the first PR and most of the discussions. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[David Waite via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>  
> 
> What is your evaluation of the proposal?
Generally +1

I would like the behavior of the generated ValueEnumerable to be defined, even 
if that behavior is based on the proposed implementation. Would this be 
declaration order? Would it be out of declaration order if a raw integer value 
was used and the cases did not have consistently increasing raw values?

I don’t know if there is an application compatibility suggestion here, such as 
‘new enumerable values should be added to the end’.

I can also understand the value of not having the static property be an 
Array to save memory, but instead be Array-like. To this end, I think the 
allValues property should have an additional constraint of an Index 
associatedtype of Int. I don’t know if there is an additional requirement for 
the indices being all the values from 0.. Is the problem being addressed significant enough to warrant a change to 
> Swift?
I think so.

> Does this proposal fit well with the feel and direction of Swift?
Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I use Java’s version of this feature a fair bit. One common extension I see is 
to convert textual names to enum values, something that it doesn’t support well 
natively. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

Thank you for the clarification. It occurred to me in the shower that this
might be the case, and that I was entirely mistaken as to what we were
talking about.

Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are
there source stability issues to 'typealias DictionaryLiteral =
[(Key, Value)]'?
On Mon, Jan 8, 2018 at 23:25 Nate Cook  wrote:

>
> On Jan 8, 2018, at 9:07 PM, Xiaodi Wu  wrote:
>
> While there’s nothing specifically to do with a dictionary, it is a
> literal in at least one essential respect. Like other literals, it doesn’t
> have a type, but values that are expressed by them do acquire a type given
> the context.
>
>
> This confusion is why we really need to rename this—there are two separate
> things:
>
> 1) *Dictionary literals.* These are written as comma-separated key-value
> pairs, with each key-value pair separated by a colon—[a: b, c: d, e: f].
> Most users of Swift have probably only ever used these to create instances
> of the Dictionary type, but any type that conforms to
> ExpressibleByDictionaryLiteral can be expressed using one. Crucially, like
> integer literals that can express an `Int` value, a `UInt8` value, or a
> value of any other integer or floating-point type, dictionary literals have 
> *no
> concrete type* until they’re evaluated in context.
>
> 2) *The `DictionaryLiteral` type.* This is a generic type that conforms
> to ExpressibleByDictionaryLiteral, but is otherwise an unremarkable
> collection with `(Key, Value)` elements. You can see its declaration here:
> https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855.
> Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type
> and can’t be used to express dictionaries or other types that conform to
> `ExpressibleByDictionaryLiteral`.
>
> It’s #2 that we’re talking about renaming, and while I think both parts of
> the name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more
> problematic because of the confusion it causes with lower-case literals.
>
> Nate
>
> Yes, it's not a dictionary, but neither is an integer literal an integer
> (or even necessarily an integer you can create from such a literal: it can
> be a floating-point value you create from that literal), etc. Would
> "ordered collection of key-value pairs" be more "correct"? By the same
> token, we ought to be renaming integer literals "ordered collection of
> digits without interposed decimal point."
>
> But essentially every user will have encountered this spelling in the
> context of dictionaries: in other words, its name has a good basis in
> reality because it is the (only) literal spelling that can be used to
> create a dictionary, and when you say "hey, that spelling you use for a
> literal to instantiate a dictionary in Swift," everyone will know what
> you're talking about.
>
> No, I think we ought to do nothing. It's not only "not bad," but as far as
> I can tell quite superior to the alternatives in essentially every respect.
> In the alternative, maybe "KeyValueLiteral" or something of that sort, but
> I still would consider that to be strictly inferior to "DictionaryLiteral".
>
>
> On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > There exists in the standard library a type `DictionaryLiteral` that
>> deserves naming re-consideration before we declare ABI Stability, because
>> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide
>> key-based lookup of values) nor a Literal.
>> >
>> > Instead, it’s just an immutable collection of key-value pairs you can
>> create _from_ a literal.
>> >
>> > I’m canvassing for opinions on what it ought to be called.  Some
>> suggestions so far:
>> >
>> > - `AssociationCollection`: Following the term of art from some other
>> languages. Slightly obscure-sounding to developers not already familiar.
>> Also “association” and “associative” are confusingly similar, which brings
>> back the is-this-a-dictionary problem.
>> > - `KeyValueCollection`: Problematic because key-value comes up in a
>> totally different context in Cocoa.
>> > - `PairCollection`: “Pair” is kinda nondescript.
>> > - Do nothing. It’s not so bad.
>>
>> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>>
>> Some more fun facts about this type:
>> - Besides Dictionary, it's the only other type in the standard library
>> that is expressible by a dictionary literal
>> - Unlike Dictionary, it *does* maintain the order of its pairs
>> - Unlike Dictionary (part 2), it *doesn't* require the first element of
>> the pairs to be Hashable
>>
>> Nate
>>
>> > The old name can live on indefinitely via a typealias (which has no ABI
>> consequences, so could be retired at a later date once everyone has had
>> plenty of time to address the 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

> On Jan 8, 2018, at 9:07 PM, Xiaodi Wu  wrote:
> 
> While there’s nothing specifically to do with a dictionary, it is a literal 
> in at least one essential respect. Like other literals, it doesn’t have a 
> type, but values that are expressed by them do acquire a type given the 
> context.

This confusion is why we really need to rename this—there are two separate 
things:

1) Dictionary literals. These are written as comma-separated key-value pairs, 
with each key-value pair separated by a colon—[a: b, c: d, e: f]. Most users of 
Swift have probably only ever used these to create instances of the Dictionary 
type, but any type that conforms to ExpressibleByDictionaryLiteral can be 
expressed using one. Crucially, like integer literals that can express an `Int` 
value, a `UInt8` value, or a value of any other integer or floating-point type, 
dictionary literals have no concrete type until they’re evaluated in context.

2) The `DictionaryLiteral` type. This is a generic type that conforms to 
ExpressibleByDictionaryLiteral, but is otherwise an unremarkable collection 
with `(Key, Value)` elements. You can see its declaration here: 
https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855.
 Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type 
and can’t be used to express dictionaries or other types that conform to 
`ExpressibleByDictionaryLiteral`.

It’s #2 that we’re talking about renaming, and while I think both parts of the 
name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more problematic 
because of the confusion it causes with lower-case literals.

Nate

> Yes, it's not a dictionary, but neither is an integer literal an integer (or 
> even necessarily an integer you can create from such a literal: it can be a 
> floating-point value you create from that literal), etc. Would "ordered 
> collection of key-value pairs" be more "correct"? By the same token, we ought 
> to be renaming integer literals "ordered collection of digits without 
> interposed decimal point."
> 
> But essentially every user will have encountered this spelling in the context 
> of dictionaries: in other words, its name has a good basis in reality because 
> it is the (only) literal spelling that can be used to create a dictionary, 
> and when you say "hey, that spelling you use for a literal to instantiate a 
> dictionary in Swift," everyone will know what you're talking about. 
> 
> No, I think we ought to do nothing. It's not only "not bad," but as far as I 
> can tell quite superior to the alternatives in essentially every respect. In 
> the alternative, maybe "KeyValueLiteral" or something of that sort, but I 
> still would consider that to be strictly inferior to "DictionaryLiteral".
> 
> 
>> On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution 
>>  wrote:
>> 
>> > On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution 
>> >  wrote:
>> >
>> > There exists in the standard library a type `DictionaryLiteral` that 
>> > deserves naming re-consideration before we declare ABI Stability, because 
>> > it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> > key-based lookup of values) nor a Literal.
>> >
>> > Instead, it’s just an immutable collection of key-value pairs you can 
>> > create _from_ a literal.
>> >
>> > I’m canvassing for opinions on what it ought to be called.  Some 
>> > suggestions so far:
>> >
>> > - `AssociationCollection`: Following the term of art from some other 
>> > languages. Slightly obscure-sounding to developers not already familiar. 
>> > Also “association” and “associative” are confusingly similar, which brings 
>> > back the is-this-a-dictionary problem.
>> > - `KeyValueCollection`: Problematic because key-value comes up in a 
>> > totally different context in Cocoa.
>> > - `PairCollection`: “Pair” is kinda nondescript.
>> > - Do nothing. It’s not so bad.
>> 
>> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>> 
>> Some more fun facts about this type:
>> - Besides Dictionary, it's the only other type in the standard library that 
>> is expressible by a dictionary literal
>> - Unlike Dictionary, it *does* maintain the order of its pairs
>> - Unlike Dictionary (part 2), it *doesn't* require the first element of the 
>> pairs to be Hashable
>> 
>> Nate
>> 
>> > The old name can live on indefinitely via a typealias (which has no ABI 
>> > consequences, so could be retired at a later date once everyone has had 
>> > plenty of time to address the deprecation warnings). Removing it as not 
>> > carrying its weight (and instead using `[(Key,Value)]`, which is basically 
>> > what it’s a wrapper for) is probably off the table for source stability 
>> > reasons.
>> >
>> > Any further thoughts welcome.
>> >
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > 

Re: [swift-evolution] [Proposal] Random Unification

[Xiaodi Wu via swift-evolution]

Agreed. This simplification is more or less precisely the shape of the
proposal that I was hoping for.

I'm worried that "optional" `random()` and "non-optional" `random()` are
spelled the same way, especially as the type is not always obvious when,
say, a range or collection is referred to by variable name and not as a
literal. And I do think that may become even more problematic should we
decide that some ranges (i.e., the countable ones) ought to conform to
Collection. (But more on that later.)

But besides that concern (which, I would hope, should not be glossed over),
I do like the direction of Nate's playground.


On Mon, Jan 8, 2018 at 5:37 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Unfortunately, it wasn’t my only worry. The simplifications from dropping
> Randomizable and random(in: ) are also very welcome for me.
>
>
> On 8 Jan 2018, at 23:08, Alejandro Alonso  wrote:
>
> I made changes last night that uses methods rather than properties if
> that’s all you’re worried about.
>
> Sent from my iPhone
>
> On Jan 8, 2018, at 15:27, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I much prefer the API from Nate Cook compared to the previous proposal.
> Its simpler, while still very powerful, and closer to Swift conventions
> (method instead of property).
>
> On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I created a playground to explore this question, starting with a minimal
> subset of the proposal’s additions and building from there. The attached
> playground demonstrates what’s possible with this subset on the first page,
> then uses subsequent pages to explore how the main random facilities of the
> C++ STL work under this model. (In my opinion, they work pretty well!)
>
> The subset in the playground has three main differences from the proposal:
>  - It doesn't include a Randomizable protocol or a random property on
> numeric types.
>  - It doesn't include the static random(in:) methods on numeric types,
> either.
>  - The RandomNumberGenerator protocol doesn't have an associated type.
> Instead, it requires all conforming types to produce UInt64 values.
>
> I’ve tried to include a bit of real-world usage in the playground to
> demonstrate what writing code would look like with these additions. Please
> take a look!
>
> Nate
>
> 
>
> On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t have much to say about this other than that I think the discussion
> seems way too narrow, focusing on spelling rather than on functionality and
> composability.  I consider the “generic random number library” design to be
> a mostly-solved problem, in the C++ standard library (
> http://en.cppreference.com/w/cpp/numeric/random).  Whatever goes into the
> Swift standard library does not need to have all those features right away,
> but should support being extended into something having the same general
> shape. IMO the right design strategy is to *implement and use* a Swift
> version of C++’s facilities and only then consider proposing [perhaps a
> subset of] that design for standardization in Swift.
>
> Sent from my iPad
>
> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Instead, we ought to make clear to users both the features and the
> limitations of this API, to encourage use where suitable and to discourage
> use where unsuitable.
>
>
> I like that you're considering the balance here. I've been lightly
> following this thread and want to add my thoughts on keeping crypto and
> pseudorandomness out of the name of at least one random API intended for
> general use.
>
> For someone who doesn't know or care about the subtleties of insecure or
> pseudorandom numbers, I'm not sure that the name insecureRandom is
> effectively much different than badRandom, at least in terms of the
> information it conveys to non-experts. To Greg's point, that's the opposite
> of the signal that the API name should suggest because it's what most
> people should use most of the time. As you say, this API is being designed
> for general use.
>
> There's a cost to adding extra complexity to names, too. I don't think
> it's far-fetched to suspect that people who find insecureRandom in an
> autocomplete listing or search will think "Where's the plain random
> function?"... and then go looking for a community extension that will
> inevitably provide a trivial alias: func random() { return
> insecureRandom() }. That's the sort of adoption I'd expect from something
> for new programmers, like Swift Playgrounds. Someone's introduction to
> randomness in programming should probably involve no more than a
> straightforward mapping from the elementary definition, rather than forcing
> a teaching moment 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

While there’s nothing specifically to do with a dictionary, it is a literal
in at least one essential respect. Like other literals, it doesn’t have a
type, but values that are expressed by them do acquire a type given the
context.

Yes, it's not a dictionary, but neither is an integer literal an integer
(or even necessarily an integer you can create from such a literal: it can
be a floating-point value you create from that literal), etc. Would
"ordered collection of key-value pairs" be more "correct"? By the same
token, we ought to be renaming integer literals "ordered collection of
digits without interposed decimal point."

But essentially every user will have encountered this spelling in the
context of dictionaries: in other words, its name has a good basis in
reality because it is the (only) literal spelling that can be used to
create a dictionary, and when you say "hey, that spelling you use for a
literal to instantiate a dictionary in Swift," everyone will know what
you're talking about.

No, I think we ought to do nothing. It's not only "not bad," but as far as
I can tell quite superior to the alternatives in essentially every respect.
In the alternative, maybe "KeyValueLiteral" or something of that sort, but
I still would consider that to be strictly inferior to "DictionaryLiteral".


On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > There exists in the standard library a type `DictionaryLiteral` that
> deserves naming re-consideration before we declare ABI Stability, because
> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide
> key-based lookup of values) nor a Literal.
> >
> > Instead, it’s just an immutable collection of key-value pairs you can
> create _from_ a literal.
> >
> > I’m canvassing for opinions on what it ought to be called.  Some
> suggestions so far:
> >
> > - `AssociationCollection`: Following the term of art from some other
> languages. Slightly obscure-sounding to developers not already familiar.
> Also “association” and “associative” are confusingly similar, which brings
> back the is-this-a-dictionary problem.
> > - `KeyValueCollection`: Problematic because key-value comes up in a
> totally different context in Cocoa.
> > - `PairCollection`: “Pair” is kinda nondescript.
> > - Do nothing. It’s not so bad.
>
> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>
> Some more fun facts about this type:
> - Besides Dictionary, it's the only other type in the standard library
> that is expressible by a dictionary literal
> - Unlike Dictionary, it *does* maintain the order of its pairs
> - Unlike Dictionary (part 2), it *doesn't* require the first element of
> the pairs to be Hashable
>
> Nate
>
> > The old name can live on indefinitely via a typealias (which has no ABI
> consequences, so could be retired at a later date once everyone has had
> plenty of time to address the deprecation warnings). Removing it as not
> carrying its weight (and instead using `[(Key,Value)]`, which is basically
> what it’s a wrapper for) is probably off the table for source stability
> reasons.
> >
> > Any further thoughts welcome.
> >
> >
> >
> > ___
> > 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] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

> On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> There exists in the standard library a type `DictionaryLiteral` that deserves 
> naming re-consideration before we declare ABI Stability, because it’s 
> confusingly misnamed, being neither a Dictionary (it doesn’t provide 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.
> 
> I’m canvassing for opinions on what it ought to be called.  Some suggestions 
> so far:
> 
> - `AssociationCollection`: Following the term of art from some other 
> languages. Slightly obscure-sounding to developers not already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.

Agreed so far, and I'd like to add CollectionOfPairs to the list.

Some more fun facts about this type:
- Besides Dictionary, it's the only other type in the standard library that is 
expressible by a dictionary literal
- Unlike Dictionary, it *does* maintain the order of its pairs
- Unlike Dictionary (part 2), it *doesn't* require the first element of the 
pairs to be Hashable

Nate

> The old name can live on indefinitely via a typealias (which has no ABI 
> consequences, so could be retired at a later date once everyone has had 
> plenty of time to address the deprecation warnings). Removing it as not 
> carrying its weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.
> 
> Any further thoughts welcome.
> 
> 
> 
> ___
> 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] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen via swift-evolution]

> On Jan 8, 2018, at 5:08 PM, Karl Wagner  wrote:
> 
> 
> 
>> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> There exists in the standard library a type `DictionaryLiteral` that 
>> deserves naming re-consideration before we declare ABI Stability, because 
>> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> key-based lookup of values) nor a Literal. 
>> 
>> Instead, it’s just an immutable collection of key-value pairs you can create 
>> _from_ a literal.
>> 
>> I’m canvassing for opinions on what it ought to be called.  Some suggestions 
>> so far:
>> 
>> - `AssociationCollection`: Following the term of art from some other 
>> languages. Slightly obscure-sounding to developers not already familiar. 
>> Also “association” and “associative” are confusingly similar, which brings 
>> back the is-this-a-dictionary problem.
>> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
>> different context in Cocoa.
>> - `PairCollection`: “Pair” is kinda nondescript.
>> - Do nothing. It’s not so bad.
>> 
>> The old name can live on indefinitely via a typealias (which has no ABI 
>> consequences, so could be retired at a later date once everyone has had 
>> plenty of time to address the deprecation warnings). Removing it as not 
>> carrying its weight (and instead using `[(Key,Value)]`, which is basically 
>> what it’s a wrapper for) is probably off the table for source stability 
>> reasons.
>> 
>> Any further thoughts welcome.
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> Since it is a generic type, could it not be nested inside of the appropriate 
> Dictionary type? That would make 2 or 3 more reasonable.
> 
> Also, what about Dictionary.KeyValuePairs?
> 
> - Karl

It’s really not related to the Dictionary type. This isn’t part of Dictionary’s 
implementation leaking out, like DictionaryIndex or DictionaryIterator were. 
It’s a separate independently (marginally-) useful type.


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Karl Wagner via swift-evolution]

> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution 
>  wrote:
> 
> There exists in the standard library a type `DictionaryLiteral` that deserves 
> naming re-consideration before we declare ABI Stability, because it’s 
> confusingly misnamed, being neither a Dictionary (it doesn’t provide 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.
> 
> I’m canvassing for opinions on what it ought to be called.  Some suggestions 
> so far:
> 
> - `AssociationCollection`: Following the term of art from some other 
> languages. Slightly obscure-sounding to developers not already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> The old name can live on indefinitely via a typealias (which has no ABI 
> consequences, so could be retired at a later date once everyone has had 
> plenty of time to address the deprecation warnings). Removing it as not 
> carrying its weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.
> 
> Any further thoughts welcome.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Since it is a generic type, could it not be nested inside of the appropriate 
Dictionary type? That would make 2 or 3 more reasonable.

Also, what about Dictionary.KeyValuePairs?

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

[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen via swift-evolution]

There exists in the standard library a type `DictionaryLiteral` that deserves 
naming re-consideration before we declare ABI Stability, because it’s 
confusingly misnamed, being neither a Dictionary (it doesn’t provide key-based 
lookup of values) nor a Literal. 

Instead, it’s just an immutable collection of key-value pairs you can create 
_from_ a literal.

I’m canvassing for opinions on what it ought to be called.  Some suggestions so 
far:

 - `AssociationCollection`: Following the term of art from some other 
languages. Slightly obscure-sounding to developers not already familiar. Also 
“association” and “associative” are confusingly similar, which brings back the 
is-this-a-dictionary problem.
 - `KeyValueCollection`: Problematic because key-value comes up in a totally 
different context in Cocoa.
 - `PairCollection`: “Pair” is kinda nondescript.
 - Do nothing. It’s not so bad.

The old name can live on indefinitely via a typealias (which has no ABI 
consequences, so could be retired at a later date once everyone has had plenty 
of time to address the deprecation warnings). Removing it as not carrying its 
weight (and instead using `[(Key,Value)]`, which is basically what it’s a 
wrapper for) is probably off the table for source stability reasons.

Any further thoughts welcome.



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

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

[Gregg Wonderly via swift-evolution]

Okay, that does work for my example.  But why wouldn’t the key also be 
available so that you might be able to have selective handling of first vs last 
for each key?

Gregg

> On Jan 8, 2018, at 4:03 PM, Nate Cook  wrote:
> 
> Hi Gregg —
> 
> The Dictionary(_:uniquingKeysWith:) initializer was added for this purpose in 
> Swift 4—please see 
> https://developer.apple.com/documentation/swift/dictionary/2892961-init 
> 
> 
> Nate
> 
>> On Jan 8, 2018, at 1:02 PM, Gregg Wonderly via swift-evolution 
>> > wrote:
>> 
>> In some dictionary implementations, key-value pairs are added with an add() 
>> method which disallows duplicate keys to be inserted with a runtime 
>> exception.  Providing an additional method of set() allows for the ability 
>> to ignore duplicate keys so that it feels more like dict[key] = value.  It 
>> might be interesting to provide this as a selectable behavior within an 
>> additional constructor's arguments.  
>> 
>> Dictionary(allowDuplicate: true, pairs: [("z", 1), ("z", 2), ("z", 3), ("z", 
>> 4)]) so that the dictionary behavior remains in line with the compile time 
>> checks.
>> 
>> Gregg
>> 
>> ___
>> 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] Renaming SwiftObject

[Greg Parker via swift-evolution]

Adding "Swift" to the mangled name is reasonable. The class is not ordinarily 
visible, so most of the time that people see it will be in potentially mangled 
contexts like crash logs.

I'm reluctant to put too much ObjC into the name, because this is the base 
class for classes that are *not* @objc. 


> On Jan 6, 2018, at 7:21 PM, Saagar Jha  wrote:
> 
> Just my 2¢, from the point of view of someone runs into SwiftObject 
> frequently: I’d really appreciate it if this class had “Swift” in it’s name. 
> At first glance, it’s name in mangled form (“_TtCs7_Object”) gives no 
> indication as to where it’s from. Obviously it’s not a “pure” Objective-C 
> object, but it’s not clear that it’s a Swift object either–maybe it’s C++? 
> Saagar’s cool new language that also does name mangling? Who knows. I guess 
> “_T” is kind of enough to figure it out, but since you’re changing the name 
> anyways it would be great if it was something that reduced my cognitive 
> overload, like Swift._SwiftObject.
> 
> If you’re going to expose this to Swift as well, a similar argument applies: 
> from it’s name, it’s not clear that it’s part of Objective-C interop. I’m not 
> sure if this is visible to Swift programmers, and if it isn’t this isn’t an 
> issue, but in the case that it is Swift._Object looks more like a private 
> implementation detail of a base class akin to NSObject in Objective-C or 
> Object in Java than a compatibility shim with Objective-C.
> 
> Saagar Jha
> 
>> On Jan 4, 2018, at 19:10, Greg Parker via swift-evolution 
>> > wrote:
>> 
>> SwiftObject is an Objective-C class that is the base class of all "pure 
>> Swift" class types. It needs to be renamed for the Swift stable ABI in order 
>> to avoid ObjC class name collisions between the stable ABI's Swift runtime 
>> and the runtime embedded into existing Swift apps.
>> 
>> I suggest `Swift._Object`, mangled as _TtCs7_Object like other Swift ObjC 
>> class names. 
>> 
>> Any comments?
>> 
>> https://github.com/apple/swift/pull/13748 
>> 
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com  Runtime 
>> Wrangler
>> 
>> 
>> ___
>> 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] Random Unification

[David Hart via swift-evolution]

Unfortunately, it wasn’t my only worry. The simplifications from dropping 
Randomizable and random(in: ) are also very welcome for me.

> On 8 Jan 2018, at 23:08, Alejandro Alonso  wrote:
> 
> I made changes last night that uses methods rather than properties if that’s 
> all you’re worried about.
> 
> Sent from my iPhone
> 
> On Jan 8, 2018, at 15:27, David Hart via swift-evolution 
> > wrote:
> 
>> I much prefer the API from Nate Cook compared to the previous proposal. Its 
>> simpler, while still very powerful, and closer to Swift conventions (method 
>> instead of property).
>> 
>>> On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution 
>>> > wrote:
>>> 
>>> I created a playground to explore this question, starting with a minimal 
>>> subset of the proposal’s additions and building from there. The attached 
>>> playground demonstrates what’s possible with this subset on the first page, 
>>> then uses subsequent pages to explore how the main random facilities of the 
>>> C++ STL work under this model. (In my opinion, they work pretty well!)
>>> 
>>> The subset in the playground has three main differences from the proposal:
>>>  - It doesn't include a Randomizable protocol or a random property on 
>>> numeric types.
>>>  - It doesn't include the static random(in:) methods on numeric types, 
>>> either.
>>>  - The RandomNumberGenerator protocol doesn't have an associated type. 
>>> Instead, it requires all conforming types to produce UInt64 values.
>>> 
>>> I’ve tried to include a bit of real-world usage in the playground to 
>>> demonstrate what writing code would look like with these additions. Please 
>>> take a look!
>>> 
>>> Nate
>>> 
>>> 
>>> 
 On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution 
 > wrote:
 
 I don’t have much to say about this other than that I think the discussion 
 seems way too narrow, focusing on spelling rather than on functionality 
 and composability.  I consider the “generic random number library” design 
 to be a mostly-solved problem, in the C++ standard library 
 (http://en.cppreference.com/w/cpp/numeric/random 
 ).  Whatever goes into 
 the Swift standard library does not need to have all those features right 
 away, but should support being extended into something having the same 
 general shape. IMO the right design strategy is to implement and use a 
 Swift version of C++’s facilities and only then consider proposing 
 [perhaps a subset of] that design for standardization in Swift.
 
 Sent from my iPad
 
 On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution 
 > wrote:
 
> 
>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> Instead, we ought to make clear to users both the features and the 
>> limitations of this API, to encourage use where suitable and to 
>> discourage use where unsuitable.
> 
> I like that you're considering the balance here. I've been lightly 
> following this thread and want to add my thoughts on keeping crypto and 
> pseudorandomness out of the name of at least one random API intended for 
> general use.
> 
> For someone who doesn't know or care about the subtleties of insecure or 
> pseudorandom numbers, I'm not sure that the name insecureRandom is 
> effectively much different than badRandom, at least in terms of the 
> information it conveys to non-experts. To Greg's point, that's the 
> opposite of the signal that the API name should suggest because it's what 
> most people should use most of the time. As you  say, this API is being 
> designed for general use.
> 
> There's a cost to adding extra complexity to names, too. I don't think 
> it's far-fetched to suspect that people who find insecureRandom in an 
> autocomplete listing or search will think "Where's the plain random 
> function?"... and then go looking for a community extension that will 
> inevitably provide a trivial alias: func random() { return 
> insecureRandom() }. That's the sort of adoption I'd expect from something 
> for new programmers, like Swift Playgrounds. Someone's introduction to 
> randomness in programming should probably involve no more than a 
> straightforward mapping from the elementary definition, rather than 
> forcing a teaching moment from more advanced math.
> 
> I think there are better places for caveat information than in the API 
> names themselves; documentation being one clear destination. This is in 
> contrast 

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Letanyan Arumugam via swift-evolution]

> What is your evaluation of the proposal?
+1 This is a very useful feature.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes for what I’ve wanted to do.

> Does this proposal fit well with the feel and direction of Swift?
It fits the design of similar synthesis features in the language.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Have not used a similar feature

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A couple read throughs

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> 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] Random Unification

[Letanyan Arumugam via swift-evolution]

> On 08 Jan 2018, at 21:02, Nate Cook via swift-evolution 
>  wrote:
> 
> I created a playground to explore this question, starting with a minimal 
> subset of the proposal’s additions and building from there. The attached 
> playground demonstrates what’s possible with this subset on the first page, 
> then uses subsequent pages to explore how the main random facilities of the 
> C++ STL work under this model. (In my opinion, they work pretty well!)
> 
> The subset in the playground has three main differences from the proposal:
>  - It doesn't include a Randomizable protocol or a random property on numeric 
> types.
>  - It doesn't include the static random(in:) methods on numeric types, either.
>  - The RandomNumberGenerator protocol doesn't have an associated type. 
> Instead, it requires all conforming types to produce UInt64 values.
> 
> I’ve tried to include a bit of real-world usage in the playground to 
> demonstrate what writing code would look like with these additions. Please 
> take a look!
> 
> Nate


+1 to this design

Just my 2 cents but this looks very simple and easy to use due to being very 
consistent. I also like that Randomizable was dropped as I feel it doesn’t hold 
its weight.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Jarod Long via swift-evolution]

>
> • What is your evaluation of the proposal?
>
+1, very happy to see this coming together! I've been interested in this 
feature since the early days of Swift.

My only reservation is that I would have expected to be able to access the list 
of values without any extra annotations. Is there a reason to not automatically 
give ValueEnumerable conformance to any enum that fits the criteria for 
synthesis?

>
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
>
Definitely, for the reasons mentioned in the proposal's motivation.

>
> • Does this proposal fit well with the feel and direction of Swift?
>
Yes, this feels like a very natural addition to the language.

>
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>
I've used the GetValues API in C#, and though I think the proposed API is a 
much better fit for Swift, I did appreciate that GetValues could be used on any 
enum without needing to opt in manually.

>
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
Full reading.


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

Re: [swift-evolution] [Proposal] Random Unification

[Alejandro Alonso via swift-evolution]

I made changes last night that uses methods rather than properties if that’s 
all you’re worried about.

Sent from my iPhone

On Jan 8, 2018, at 15:27, David Hart via swift-evolution 
> wrote:

I much prefer the API from Nate Cook compared to the previous proposal. Its 
simpler, while still very powerful, and closer to Swift conventions (method 
instead of property).

On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution 
> wrote:

I created a playground to explore this question, starting with a minimal subset 
of the proposal’s additions and building from there. The attached playground 
demonstrates what’s possible with this subset on the first page, then uses 
subsequent pages to explore how the main random facilities of the C++ STL work 
under this model. (In my opinion, they work pretty well!)

The subset in the playground has three main differences from the proposal:
 - It doesn't include a Randomizable protocol or a random property on numeric 
types.
 - It doesn't include the static random(in:) methods on numeric types, either.
 - The RandomNumberGenerator protocol doesn't have an associated type. Instead, 
it requires all conforming types to produce UInt64 values.

I’ve tried to include a bit of real-world usage in the playground to 
demonstrate what writing code would look like with these additions. Please take 
a look!

Nate



On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution 
> wrote:

I don’t have much to say about this other than that I think the discussion 
seems way too narrow, focusing on spelling rather than on functionality and 
composability.  I consider the “generic random number library” design to be a 
mostly-solved problem, in the C++ standard library 
(http://en.cppreference.com/w/cpp/numeric/random).  Whatever goes into the 
Swift standard library does not need to have all those features right away, but 
should support being extended into something having the same general shape. IMO 
the right design strategy is to implement and use a Swift version of C++’s 
facilities and only then consider proposing [perhaps a subset of] that design 
for standardization in Swift.

Sent from my iPad

On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution 
> wrote:


On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
> wrote:

Instead, we ought to make clear to users both the features and the limitations 
of this API, to encourage use where suitable and to discourage use where 
unsuitable.

I like that you're considering the balance here. I've been lightly following 
this thread and want to add my thoughts on keeping crypto and pseudorandomness 
out of the name of at least one random API intended for general use.

For someone who doesn't know or care about the subtleties of insecure or 
pseudorandom numbers, I'm not sure that the name insecureRandom is effectively 
much different than badRandom, at least in terms of the information it conveys 
to non-experts. To Greg's point, that's the opposite of the signal that the API 
name should suggest because it's what most people should use most of the time. 
As you say, this API is being designed for general use.

There's a cost to adding extra complexity to names, too. I don't think it's 
far-fetched to suspect that people who find insecureRandom in an autocomplete 
listing or search will think "Where's the plain random function?"... and then 
go looking for a community extension that will inevitably provide a trivial 
alias: func random() { return insecureRandom() }. That's the sort of adoption 
I'd expect from something for new programmers, like Swift Playgrounds. 
Someone's introduction to randomness in programming should probably involve no 
more than a straightforward mapping from the elementary definition, rather than 
forcing a teaching moment from more advanced math.

I think there are better places for caveat information than in the API names 
themselves; documentation being one clear destination. This is in contrast with 
Unsafe*Pointer, where the safety element is critical enough to be elevated to 
be more than caveat-level information. You can go really far and create really 
cool things before these caveats start to apply. Using randomness as a black 
box in an intro programming environment seems like a much more common scenario 
than someone attempting to roll their first crypto by only reading API names 
and hoping for the best.

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

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

[Nate Cook via swift-evolution]

Hi Gregg —

The Dictionary(_:uniquingKeysWith:) initializer was added for this purpose in 
Swift 4—please see 
https://developer.apple.com/documentation/swift/dictionary/2892961-init

Nate

> On Jan 8, 2018, at 1:02 PM, Gregg Wonderly via swift-evolution 
>  wrote:
> 
> In some dictionary implementations, key-value pairs are added with an add() 
> method which disallows duplicate keys to be inserted with a runtime 
> exception.  Providing an additional method of set() allows for the ability to 
> ignore duplicate keys so that it feels more like dict[key] = value.  It might 
> be interesting to provide this as a selectable behavior within an additional 
> constructor's arguments.  
> 
> Dictionary(allowDuplicate: true, pairs: [("z", 1), ("z", 2), ("z", 3), ("z", 
> 4)]) so that the dictionary behavior remains in line with the compile time 
> checks.
> 
> Gregg
> 
> ___
> 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] Questions about non-exhaustive enums

[Jordan Rose via swift-evolution]

Good questions. The answer at a high level is "you break binary and source 
compatibility", and if you care about binary compatibility everything will fall 
to pieces (read: crashes, possibly undefined behavior). So our only goal on the 
binary compatibility is to make the "falling to pieces" as deterministic as 
possible, as described as a "Future direction"; we want library authors to not 
do this by mistake, and if they do we want apps to fail to launch rather than 
potentially corrupting user data.

For libraries that don't care about binary compatibility, breaking source 
compatibility is an option, if not one to be taken lightly. So:

- Adding a case to a frozen enum will result in errors in all switch statements 
without catch-all cases ('default' or '_' patterns), with the diagnostic saying 
that there is now an unhandled pattern. This is essentially the behavior of 
enums in Swift 4.

- Changing an enum from frozen to non-frozen will result in errors in all 
switch statements without catch-all cases, with the diagnostic saying that a 
switch over a non-frozen enum must include a catch-all pattern or `unknown 
case`. This is the diagnostic people will see when migrating from Swift 4 to 
Swift 5, so it has to be good anyway.

I'll add this to the proposal. Thanks, Nacho!

Jordan


> On Jan 5, 2018, at 10:54, Ignacio Soto via swift-evolution 
>  wrote:
> 
> I love the revision to the proposal 
> , but I have a couple of 
> remaining questions that don't seem to be addressed in the doc and I'm 
> curious about:
> What happens if a library maintainer adds a new case to a @frozen enum?
> What happens if a library maintainer changes an enum from @frozen to 
> non-frozen?
> Thanks!
> 
> 
> -- 
> Ignacio Soto
> ___
> 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] [Review] SE-0194: Derived Collection of Enum Cases

[Rod Brown via swift-evolution]

> What is your evaluation of the proposal?
+1 to the idea. Disappointing that we don’t seem to be able to add this to 
@objc enums. Could we come up with some kind of workaround for this?

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, this is a common problem where I constantly write all case static 
properties, and where I use the count. To be honest, for such a robust system, 
I found it a glaring omission.

> Does this proposal fit well with the feel and direction of Swift?
Yes, the way the proposed solution is designed seems to work well.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve done a lot of hacked enum “allCases” implementations in Swift, and we 
really didn’t have this power in the other languages I’ve used.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick reading.

Sent from my iPad

> On 9 Jan 2018, at 6:02 am, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs 
> through January 11, 2018. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> 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] Random Unification

[David Hart via swift-evolution]

I much prefer the API from Nate Cook compared to the previous proposal. Its 
simpler, while still very powerful, and closer to Swift conventions (method 
instead of property).

> On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution 
>  wrote:
> 
> I created a playground to explore this question, starting with a minimal 
> subset of the proposal’s additions and building from there. The attached 
> playground demonstrates what’s possible with this subset on the first page, 
> then uses subsequent pages to explore how the main random facilities of the 
> C++ STL work under this model. (In my opinion, they work pretty well!)
> 
> The subset in the playground has three main differences from the proposal:
>  - It doesn't include a Randomizable protocol or a random property on numeric 
> types.
>  - It doesn't include the static random(in:) methods on numeric types, either.
>  - The RandomNumberGenerator protocol doesn't have an associated type. 
> Instead, it requires all conforming types to produce UInt64 values.
> 
> I’ve tried to include a bit of real-world usage in the playground to 
> demonstrate what writing code would look like with these additions. Please 
> take a look!
> 
> Nate
> 
> 
> 
>> On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> I don’t have much to say about this other than that I think the discussion 
>> seems way too narrow, focusing on spelling rather than on functionality and 
>> composability.  I consider the “generic random number library” design to be 
>> a mostly-solved problem, in the C++ standard library 
>> (http://en.cppreference.com/w/cpp/numeric/random 
>> ).  Whatever goes into the 
>> Swift standard library does not need to have all those features right away, 
>> but should support being extended into something having the same general 
>> shape. IMO the right design strategy is to implement and use a Swift version 
>> of C++’s facilities and only then consider proposing [perhaps a subset of] 
>> that design for standardization in Swift.
>> 
>> Sent from my iPad
>> 
>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution 
>> > wrote:
>> 
>>> 
 On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 Instead, we ought to make clear to users both the features and the 
 limitations of this API, to encourage use where suitable and to discourage 
 use where unsuitable.
>>> 
>>> I like that you're considering the balance here. I've been lightly 
>>> following this thread and want to add my thoughts on keeping crypto and 
>>> pseudorandomness out of the name of at least one random API intended for 
>>> general use.
>>> 
>>> For someone who doesn't know or care about the subtleties of insecure or 
>>> pseudorandom numbers, I'm not sure that the name insecureRandom is 
>>> effectively much different than badRandom, at least in terms of the 
>>> information it conveys to non-experts. To Greg's point, that's the opposite 
>>> of the signal that the API name should suggest because it's what most 
>>> people should use most of the time. As you say, this API is being designed 
>>> for general use.
>>> 
>>> There's a cost to adding extra complexity to names, too. I don't think it's 
>>> far-fetched to suspect that people who find insecureRandom in an 
>>> autocomplete listing or search will think "Where's the plain random 
>>> function?"... and then go looking for a community extension that will 
>>> inevitably provide a trivial alias: func random() { return insecureRandom() 
>>> }. That's the sort of adoption I'd expect from something for new 
>>> programmers, like Swift Playgrounds. Someone's introduction to randomness 
>>> in programming should probably involve no more than a straightforward 
>>> mapping from the elementary definition, rather than forcing a teaching 
>>> moment from more advanced math.
>>> 
>>> I think there are better places for caveat information than in the API 
>>> names themselves; documentation being one clear destination. This is in 
>>> contrast with Unsafe*Pointer, where the safety element is critical enough 
>>> to be elevated to be more than caveat-level information. You can go really 
>>> far and create really cool things before these caveats start to apply. 
>>> Using randomness as a black box in an intro programming environment seems 
>>> like a much more common scenario than someone attempting to roll their 
>>> first crypto by only reading API names and hoping for the best.
>>> 
>>> -Kyle
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
I’m hugely in favour of the proposal but am quite worried about that fact that 
ValueEnumerable will not work for @objc enums and enums imported from C/Obj-C 
headers. It seems like a very common scenario and the lack of support for it 
will be both surprising and fustrating. Is there no way around it?

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes.

> Does this proposal fit well with the feel and direction of Swift?
Yes, apart from the Objective-C support.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Very few languages provide this functionality and I am very happy that Swift is 
finally providing it.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Several reads.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> 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] [Review] SE 0192 - Non-Exhaustive Enums

[Jordan Rose via swift-evolution]

It's true that Apple framework authors have this capability, known as a 
"linked-on-or-after check", but it has several caveats:

- It can only check what SDK the application was linked against. Any prebuilt 
libraries that the application uses might have been built against an older or 
newer SDK. (Yes, Apple discourages linking against libraries you didn't build 
yourself; at the same time we all know people do it.)

- The check is "what SDK was the application linked against". That means that a 
developer is opting into all new behavior when they update to a new SDK, 
instead of just one API's.

- The whole system still has to work together, so it's not always possible to 
preserve the old behavior.

- This means that it's not true that "every library actually keeps old 
implementations around". What happens is that individual frameworks may choose 
to do a "linked-on-or-after" check for a particular feature, and modify their 
behavior based on that. They may also choose not to, which might make sense 
for, e.g., a new UIView animation kind, or a new property list serialization 
kind.

I haven't looked at all, but I suspect the vast majority of changes between 
Apple OS releases, including new cases added to enums, are not guarded by 
linked-on-or-after checks. (I probably can't look, or at least can't tell you, 
because anything not release-noted might be left that way for a reason.) You 
may have been thinking of, say, the .NET approach to compatibility 
,
 where Microsoft actually does ship several copies of the standard library and 
runtimes when they make major breaking changes, but even then they don't do 
this for every single OS update.


I think Jon's original point has been answered by now: this is an issue in 
Objective-C, but not one that leads to undefined behavior, because in effect 
the compiler treats all C enums as "non-exhaustive" except in warnings. (You 
can imagine a `default: break;` inserted at the end of any switch that doesn't 
otherwise have one in C.)

Jordan


> On Jan 8, 2018, at 11:02, Saagar Jha via swift-evolution 
>  wrote:
> 
> (Disclaimer: I’m no expert in this, and I know there are people in this list 
> that are, so if there’s anything wrong please feel free to step in and 
> correct me)
> 
> As far as I’m aware, Apple’s frameworks check which version of the framework 
> you linked with at runtime (for UIKit, I believe this function is 
> UIApplicationLinkedOnOrAfter) and modify their behavior to match. For 
> example, if this function shows your application was linked with the iOS 6 
> SDK you’d get the old skeuomorphic UI instead of the “flatter”, newer iOS 
> 7-style controls. What this means is every library actually keeps old 
> implementations around in addition to the newer ones and picks the necessary 
> one at runtime, so binary compatibility boils down to things like “don't 
> change the memory layout of classes” rather than “don’t change the behavior 
> of your program”.
> 
> Saagar Jha
> 
>> On Jan 5, 2018, at 19:11, Jon Shier via swift-evolution 
>> > wrote:
>> 
>> At this point I think it might be useful to outline how binary compatibility 
>> works for Objective-C on Apple platforms right now. As an app developer I’m 
>> not intimately familiar with what happens when you run an app compiled with 
>> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
>> paths or something else? The more this thread goes on the more confused I 
>> get about why Swift would have this issue while it doesn’t appear to be one 
>> for Obj-C. If an enum adds a case now, I don’t have to care until I 
>> recompile using the new SDK. Is the intention for Swift to be different in 
>> this regard?
>> 
>> 
>> 
>> Jon Shier
>> 
>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
 On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
 > wrote:
 
 Is it hard to imagine that most everyone can get what they want and keep 
 the syntax clean and streamlined at the same time? Without any "@" signs 
 or other compiler hints?
>>> 
>>> For what it's worth, the original version of the proposal started with a 
>>> modifier (a context-sensitive keyword, like 'final'), but the core team 
>>> felt that there were a lot of modifiers in the language already, and this 
>>> didn't meet the bar.
>>> 
>>> 
 "Rather, we are how to enable the vendor of a nonexhaustive enum to add 
 new cases without breaking binaries compiled against previous versions"
 
 When an enum changes, and the change causes the code to break, the user 
 can be presented with migration options from an automated IDE tool. In 

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

[Goffredo Marocchi via swift-evolution]

Add -Weverything and you can ensure you are switching exhaustively ;).

Sent from my iPhone

> On 8 Jan 2018, at 19:02, Javier Soto via swift-evolution 
>  wrote:
> 
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined 
> with cases A, B, and C, this switch is correct:
> 
> int foo;
> swith (e) { 
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
> 
> (Note the lack of a default case)
> 
> If that enum is defined in a framework and it changes after the app is 
> compiled (like it's the case with Apple frameworks), then that code produces 
> no warning, yet the foo variable will have a garbage value (undefined 
> behavior, but as far as the compiler can tell at compile time your code is 
> fine)
> 
> Adding a default clause to that switch has the downside of not getting 
> warnings for new added cases, like has been discussed before, which is very 
> useful.
>> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution 
>>  wrote:
>> At this point I think it might be useful to outline how binary compatibility 
>> works for Objective-C on Apple platforms right now. As an app developer I’m 
>> not intimately familiar with what happens when you run an app compiled with 
>> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
>> paths or something else? The more this thread goes on the more confused I 
>> get about why Swift would have this issue while it doesn’t appear to be one 
>> for Obj-C. If an enum adds a case now, I don’t have to care until I 
>> recompile using the new SDK. Is the intention for Swift to be different in 
>> this regard?
>> 
>> 
>> 
>> Jon Shier
>> 
>>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
  wrote:
 
 Is it hard to imagine that most everyone can get what they want and keep 
 the syntax clean and streamlined at the same time? Without any "@" signs 
 or other compiler hints?
>>> 
>>> For what it's worth, the original version of the proposal started with a 
>>> modifier (a context-sensitive keyword, like 'final'), but the core team 
>>> felt that there were a lot of modifiers in the language already, and this 
>>> didn't meet the bar.
>>> 
>>> 
> "Rather, we are how to enable the vendor of a nonexhaustive enum to add 
> new cases without breaking binaries compiled against previous versions"
 
 When an enum changes, and the change causes the code to break, the user 
 can be presented with migration options from an automated IDE tool. In 
 what specific way does this not solve the issue about having to upgrade 
 your code when using someone else's code library? This very notion implies 
 your disgruntled about doing work when things are upgraded, is that really 
 what this fuss is all about?
 
 A well written language interpreter and auto-tooling IDE would not need 
 hints embedded in the code syntax itself. Migration hints from version to 
 version should not be a part of either the past or future version of the 
 code library.
>>> 
>>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>>> because if there's a new enum case, it's unclear what you want to do with 
>>> it. If you're handling errors, it's not obvious that the way you've handled 
>>> any of the other errors is appropriate. In the (admittedly controversial) 
>>> SKPaymentTransactionState case, none of the existing code would be 
>>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>>> StoreKit provide "template" code that would be appropriate to the client 
>>> app.
>>> 
>>> 
>>> In any case, though, the key point on this particular quoted sentence is 
>>> "without breaking binaries". Any such change must be valid without 
>>> recompilation, and indeed without any intervention from the developer or an 
>>> IDE, because that's what happens when the user updates their OS.
>>> 
>>> Jordan
>>> 
>>> 
>>> 
 
 ...
 
 I don't expect the community to agree on language grammar, but the common 
 sense here on how to achieve the intended goals seems to be out of wack.
 
 If someone can present a clear logical statement as to how an automated 
 migration tool behind the scenes in the IDE to handle all your versioning 
 worries, does not make this whole discussion about adding more convoluted 
 syntax additions irrelevant, I'd love to hear it.
 
 ___
 
 Sincerely,
 Jason
 
 
 
 
 
 
> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>  wrote:
> 
>> I think this whole thing has been 

Re: [swift-evolution] [swift-corelibs-dev] Discourse rollout re-schedule

[Nicole Jacque via swift-evolution]

We did a re-set of the forum content and it overwrote all the temporary data.  
I’ll put up new instructions and pin them to the front page.

> On Jan 6, 2018, at 3:13 PM, Lars Sonchocky-Helldorf 
>  wrote:
> 
> Hi Nicole,
> 
>> Am 15.12.2017 um 03:59 schrieb Nicole Jacque via swift-corelibs-dev 
>> >:
>> 
>> Hi All-
>> 
>> First of all, a big thank you to everyone who has provided feedback on our 
>> prototype Discourse forum.  Based on the fact that we’re still receiving 
>> feedback, we’d like to move to a slightly less aggressive schedule for our 
>> rollout, in order to make sure that we’ve adequately addressed it.  We’re 
>> still working out an exact schedule, but due to the upcoming holidays, I 
>> expect that we’ll be looking at shortly after the beginning of the new year.
>> 
>> In the meantime, I’ve moved the prototype forum to https://forums.swift.org 
>> , and I have GitHub-enabled logins working if 
>> you’d like to give it a try!  You can also test out registering (including 
>> using the staged account pre-created from your mailing list account).  
>> Instructions are here: 
>> https://forums.swift.org/t/taking-over-a-pre-created-staged-account/7121 
>> 
> 
> that link doesn’t work for me, it redirects me to:
> 
> https://forums.swift.org/t/synthesizing-equatable-hashable-and-comparable-for-tuple-types/7121
>  
> 
> 
> I am missing something?
> 
> Thanks and happy new year,
> 
>   Lars

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

[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs 
through January 11, 2018. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
Reply text
Other replies
 
What
 goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

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

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Karl Wagner via swift-evolution]

> On 7. Jan 2018, at 18:47, Robert Widmann  wrote:
> 
> 
> 
> ~Robert Widmann 
> 
> 2017/12/31 11:02、Karl Wagner via swift-evolution  >のメール:
> 
>> 
>> 
>>> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> Sorry for the delay. I've just updated the proposal text to incorporate 
>>> various changes, some contributed by others.
>>> 
>>> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>>>  
>>> 
>>> 
>>> Robert's implementation 
>>>  
>>> is a good start, but will need to be updated to match the naming choice in 
>>> the final proposal, and to use associatedtype.
>> 
>> 
>> Looks good, but I have two questions:
>> 
>> 1) What is the exact semantic meaning of ValueEnumerable? Does it somehow 
>> imply an enum? Or is it simply an abstraction for any type with a “fixed, 
>> finite set of [values]”?
> 
> The exact meaning of a synthesized conformance to ValueEnumerable is
> 
> - The type is an enum
> - That enum is not @objc
> - That enum is composed entirely of cases that have no associated values
> - That enum is defined in the module declaring the synthesized conformance 
> (ie no extensions - same as Equatable and Hashable)
> 
> The exact meaning of a general conformance is
> 
> - The type has a finite number of possible values inhabiting it
> 
> As you note, integral types and Bool and some enums that fall outside the 
> scope of the synthesis requirements fit this mold quite nicely.  We do not 
> include them in the proposal partially to keep things simple, partially 
> because we’d be stepping on Range’s toes, and partially because synthesis for 
> structs is tricky in the general case.  If deemed particularly useful in the 
> future, these conformance can be added.
> 
>> 
>> 2) Is the order of values in the Collection generally meaningful, or not? If 
>> not, would it be reasonable for types which conform to Comparable to always 
>> return a sorted Collection? Or should we manually sort it with 
>> “MyEnum.allValues.sorted()”?
> 
> The interface for the protocol makes no ordering guarantees, but the 
> synthesized conformance uses source-order because that’s currently the way 
> the runtime metadata (which will become ABI) is implemented.  It is up to 
> authors to document the ordering stability of the value collection or to let 
> the compiler handle it for them.
> 
> ~Robert Widmann
> 

Cool. I definitely think it’s worth having this protocol in the standard 
library.

- Karl

>> 
>> - Karl
>> 
>>> 
>>> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
>>> > 
>>> wrote:
>>> Has this stalled out again? I would like to help with the proposal and even 
>>> attempt implementation. 
>>> 
>>> I also need to catch up on the resilient discussion regarding enum case 
>>> ordering. 
>>> 
>>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
 
 
 Jacob Bandes-Storch
 
 On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon 
 > wrote:
> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  > wrote:
> 
> 1. It must be possible to easily access the count of values, and to 
> access any particular value using contiguous `Int` indices. This could be 
> achieved either by directly accessing elements in the list of values 
> through an Int subscript, or by constructing an Array from the list of 
> values.
> 
> 2. It must be possible to control the order of values in the list of 
> values, either by using source order or through some other simple, 
> straightforward mechanism.
>  
> OK, first of all, nowhere in the proposal text are these requirements 
> stated as part of the use case. You're free to put forward new use cases, 
> but here I am trying to design the most elegant way to fulfill a stated 
> need and you're telling me that it's something other than what's written.
 
 Honestly, re-reading the proposal, it never cites a fully-formed use case. 
 Instead, it cites several blog posts, Stack Overflow questions, and small 
 code samples without digging in to the underlying reasons why developers 
 are doing what they're doing. Most of the people discussing it so far seem 
 to have had a tacit understanding that we wanted roughly Array-like 
 access, but we haven't explicitly dug into which properties 

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

[Dominik Pich via swift-evolution]

hello,
im not sure I like this. I think new cases to switches should always break an 
app. :)

> Am 19.12.2017 um 14:58 schrieb Ted Kremenek via swift-evolution 
> :
> 
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
> January 3, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift.
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
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

[Jon Shier via swift-evolution]

Which isn’t a problem right now, AFAICT. Apps compiled under older SDKs 
continue to work fine (sometimes better than when compiled under the new SDK, 
as the older one avoids new bugs). My question is about how that compatibility 
is accomplished today and how and why the Obj-C and Swift cases are apparently 
different here. 



Jon

> On Jan 6, 2018, at 6:12 PM, Javier Soto  wrote:
> 
> What doesn't happen today? The issue is not when they ship a new SDK: When 
> rebuilding your app against it, you'll get a warning for a missing case. The 
> problem is when running the app against a newer iOS version with a newer 
> version of the SDK where the enum has a new case.
>> On Sat, Jan 6, 2018 at 3:10 PM Jon Shier  wrote:
>> Except it clearly doesn’t happen today when Apple ships new SDKs. Obviously 
>> there’s an alternate mechanism used in that case. I’m just curious what it 
>> is and why Swift so desperately needs an alternative.  
>> 
>> 
>> Jon
>> 
>>> On Jan 6, 2018, at 5:49 PM, Javier Soto  wrote:
>>> 
>>> This is very much an issue in Obj-C today. If you have an NS_ENUM defined 
>>> with cases A, B, and C, this switch is correct:
>>> 
>>> int foo;
>>> swith (e) { 
>>> case A: foo = 0; break;
>>> case B: foo = 1; break;
>>> case C: foo = 2; break;
>>> }
>>> 
>>> (Note the lack of a default case)
>>> 
>>> If that enum is defined in a framework and it changes after the app is 
>>> compiled (like it's the case with Apple frameworks), then that code 
>>> produces no warning, yet the foo variable will have a garbage value 
>>> (undefined behavior, but as far as the compiler can tell at compile time 
>>> your code is fine)
>>> 
>>> Adding a default clause to that switch has the downside of not getting 
>>> warnings for new added cases, like has been discussed before, which is very 
>>> useful.
 On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution 
  wrote:
 At this point I think it might be useful to outline how binary 
 compatibility works for Objective-C on Apple platforms right now. As an 
 app developer I’m not intimately familiar with what happens when you run 
 an app compiled with the iOS 10 SDK on iOS 11. Are there just runtime 
 checks to call old code paths or something else? The more this thread goes 
 on the more confused I get about why Swift would have this issue while it 
 doesn’t appear to be one for Obj-C. If an enum adds a case now, I don’t 
 have to care until I recompile using the new SDK. Is the intention for 
 Swift to be different in this regard?
 
 
 
 Jon Shier
 
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
>>  wrote:
>> 
>> Is it hard to imagine that most everyone can get what they want and keep 
>> the syntax clean and streamlined at the same time? Without any "@" signs 
>> or other compiler hints?
> 
> For what it's worth, the original version of the proposal started with a 
> modifier (a context-sensitive keyword, like 'final'), but the core team 
> felt that there were a lot of modifiers in the language already, and this 
> didn't meet the bar.
> 
> 
>>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add 
>>> new cases without breaking binaries compiled against previous versions"
>> 
>> When an enum changes, and the change causes the code to break, the user 
>> can be presented with migration options from an automated IDE tool. In 
>> what specific way does this not solve the issue about having to upgrade 
>> your code when using someone else's code library? This very notion 
>> implies your disgruntled about doing work when things are upgraded, is 
>> that really what this fuss is all about?
>> 
>> A well written language interpreter and auto-tooling IDE would not need 
>> hints embedded in the code syntax itself. Migration hints from version 
>> to version should not be a part of either the past or future version of 
>> the code library.
> 
> Thanks for bringing this up! Unfortunately, it falls down in practice, 
> because if there's a new enum case, it's unclear what you want to do with 
> it. If you're handling errors, it's not obvious that the way you've 
> handled any of the other errors is appropriate. In the (admittedly 
> controversial) SKPaymentTransactionState case, none of the existing code 
> would be appropriate to handle the newly-introduced "deferred" case, and 
> nor could StoreKit provide "template" code that would be appropriate to 
> the client app.
> 
> 
> In any case, though, the key point on this particular quoted sentence is 
> "without breaking 

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Robert Widmann via swift-evolution]

~Robert Widmann 

2017/12/31 11:02、Karl Wagner via swift-evolution 
のメール:

> 
> 
>> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution 
>>  wrote:
>> 
>> Sorry for the delay. I've just updated the proposal text to incorporate 
>> various changes, some contributed by others.
>> 
>> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>> 
>> Robert's implementation is a good start, but will need to be updated to 
>> match the naming choice in the final proposal, and to use associatedtype.
> 
> 
> Looks good, but I have two questions:
> 
> 1) What is the exact semantic meaning of ValueEnumerable? Does it somehow 
> imply an enum? Or is it simply an abstraction for any type with a “fixed, 
> finite set of [values]”?

The exact meaning of a synthesized conformance to ValueEnumerable is

- The type is an enum
- That enum is not @objc
- That enum is composed entirely of cases that have no associated values
- That enum is defined in the module declaring the synthesized conformance (ie 
no extensions - same as Equatable and Hashable)

The exact meaning of a general conformance is

- The type has a finite number of possible values inhabiting it

As you note, integral types and Bool and some enums that fall outside the scope 
of the synthesis requirements fit this mold quite nicely.  We do not include 
them in the proposal partially to keep things simple, partially because we’d be 
stepping on Range’s toes, and partially because synthesis for structs is tricky 
in the general case.  If deemed particularly useful in the future, these 
conformance can be added.

> 
> 2) Is the order of values in the Collection generally meaningful, or not? If 
> not, would it be reasonable for types which conform to Comparable to always 
> return a sorted Collection? Or should we manually sort it with 
> “MyEnum.allValues.sorted()”?

The interface for the protocol makes no ordering guarantees, but the 
synthesized conformance uses source-order because that’s currently the way the 
runtime metadata (which will become ABI) is implemented.  It is up to authors 
to document the ordering stability of the value collection or to let the 
compiler handle it for them.

~Robert Widmann

> 
> - Karl
> 
>> 
>>> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
>>>  wrote:
>>> Has this stalled out again? I would like to help with the proposal and even 
>>> attempt implementation. 
>>> 
>>> I also need to catch up on the resilient discussion regarding enum case 
>>> ordering. 
>>> 
 On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
  wrote:
 
 
 
 Jacob Bandes-Storch
 
 On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon 
  wrote:
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>>> 
>>> 1. It must be possible to easily access the count of values, and to 
>>> access any particular value using contiguous `Int` indices. This could 
>>> be achieved either by directly accessing elements in the list of values 
>>> through an Int subscript, or by constructing an Array from the list of 
>>> values.
>>> 
>>> 2. It must be possible to control the order of values in the list of 
>>> values, either by using source order or through some other simple, 
>>> straightforward mechanism.
>>  
>> OK, first of all, nowhere in the proposal text are these requirements 
>> stated as part of the use case. You're free to put forward new use 
>> cases, but here I am trying to design the most elegant way to fulfill a 
>> stated need and you're telling me that it's something other than what's 
>> written.
> 
> Honestly, re-reading the proposal, it never cites a fully-formed use 
> case. Instead, it cites several blog posts, Stack Overflow questions, and 
> small code samples without digging in to the underlying reasons why 
> developers are doing what they're doing. Most of the people discussing it 
> so far seem to have had a tacit understanding that we wanted roughly 
> Array-like access, but we haven't explicitly dug into which properties of 
> an Array are important.
> 
> (If anyone involved feels like they had a different understanding of the 
> use case, please speak up.)
> 
> I think this is a place where the proposal can be improved, and I'm 
> willing to do some writing to improve it.
 
 For the record, I would be happy to add co-authors (or even relinquish 
 authorship entirely—I don't really care whose name is on this, it just 
 needs to happen!) if you or anyone else has improved wording, motivation, 
 justification, etc. to contribute.
 ___
 swift-evolution mailing list
 

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

[Javier Soto via swift-evolution]

What doesn't happen today? The issue is not when they ship a new SDK: When
rebuilding your app against it, you'll get a warning for a missing case.
The problem is when running the app against a newer iOS version with a
newer version of the SDK where the enum has a new case.
On Sat, Jan 6, 2018 at 3:10 PM Jon Shier  wrote:

> Except it clearly doesn’t happen today when Apple ships new SDKs.
> Obviously there’s an alternate mechanism used in that case. I’m just
> curious what it is and why Swift so desperately needs an alternative.
>
>
> Jon
>
> On Jan 6, 2018, at 5:49 PM, Javier Soto  wrote:
>
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined
> with cases A, B, and C, this switch is correct:
>
> int foo;
> swith (e) {
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
>
> (Note the lack of a default case)
>
> If that enum is defined in a framework and it changes after the app is
> compiled (like it's the case with Apple frameworks), then that code
> produces no warning, yet the foo variable will have a garbage value
> (undefined behavior, but as far as the compiler can tell at compile time
> your code is fine)
>
> Adding a default clause to that switch has the downside of not getting
> warnings for new added cases, like has been discussed before, which is very
> useful.
> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> At this point I think it might be useful to outline how binary
>> compatibility works for Objective-C on Apple platforms right now. As an app
>> developer I’m not intimately familiar with what happens when you run an app
>> compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to
>> call old code paths or something else? The more this thread goes on the
>> more confused I get about why Swift would have this issue while it doesn’t
>> appear to be one for Obj-C. If an enum adds a case now, I don’t have to
>> care until I recompile using the new SDK. Is the intention for Swift to be
>> different in this regard?
>>
>>
>>
>> Jon Shier
>>
>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Is it hard to imagine that most everyone can get what they want and keep
>> the syntax clean and streamlined at the same time? Without any "@" signs or
>> other compiler hints?
>>
>>
>> For what it's worth, the original version of the proposal started with a
>> modifier (a context-sensitive keyword, like 'final'), but the core team
>> felt that there were a lot of modifiers in the language already, and this
>> didn't meet the bar.
>>
>>
>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add
>>> new cases without breaking binaries compiled against previous versions"
>>
>>
>> When an enum changes, and the change causes the code to break, the user
>> can be presented with migration options from an automated IDE tool. In what
>> specific way does this not solve the issue about having to upgrade your
>> code when using someone else's code library? This very notion implies your
>> disgruntled about doing work when things are upgraded, is that really what
>> this fuss is all about?
>>
>> A well written language interpreter and auto-tooling IDE would not need
>> hints embedded in the code syntax itself. Migration hints from version to
>> version should not be a part of either the past or future version of the
>> code library.
>>
>>
>> Thanks for bringing this up! Unfortunately, it falls down in practice,
>> because if there's a new enum case, *it's unclear what you want to do
>> with it.* If you're handling errors, it's not obvious that the way
>> you've handled any of the *other* errors is appropriate. In the
>> (admittedly controversial) SKPaymentTransactionState case, none of the
>> existing code would be appropriate to handle the newly-introduced
>> "deferred" case, and nor could StoreKit provide "template" code that would
>> be appropriate to the client app.
>>
>>
>> In any case, though, the key point on this particular quoted sentence is
>> "without breaking *binaries"*. Any such change must be valid *without* 
>> recompilation,
>> and indeed without any intervention from the developer or an IDE, because
>> that's what happens when the user updates their OS.
>>
>> Jordan
>>
>>
>>
>>
>> ...
>>
>> I don't expect the community to agree on language grammar, but the common
>> sense here on how to achieve the intended goals seems to be out of wack.
>>
>> If someone can present a clear logical statement as to how an automated
>> migration tool behind the scenes in the IDE to handle all your versioning
>> worries, does not make this whole discussion about adding more convoluted
>> syntax additions irrelevant, I'd love to hear it.
>>
>> ___
>>
>> 

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

[Jon Shier via swift-evolution]

Except it clearly doesn’t happen today when Apple ships new SDKs. Obviously 
there’s an alternate mechanism used in that case. I’m just curious what it is 
and why Swift so desperately needs an alternative.  


Jon

> On Jan 6, 2018, at 5:49 PM, Javier Soto  wrote:
> 
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined 
> with cases A, B, and C, this switch is correct:
> 
> int foo;
> swith (e) { 
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
> 
> (Note the lack of a default case)
> 
> If that enum is defined in a framework and it changes after the app is 
> compiled (like it's the case with Apple frameworks), then that code produces 
> no warning, yet the foo variable will have a garbage value (undefined 
> behavior, but as far as the compiler can tell at compile time your code is 
> fine)
> 
> Adding a default clause to that switch has the downside of not getting 
> warnings for new added cases, like has been discussed before, which is very 
> useful.
>> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution 
>>  wrote:
>> At this point I think it might be useful to outline how binary compatibility 
>> works for Objective-C on Apple platforms right now. As an app developer I’m 
>> not intimately familiar with what happens when you run an app compiled with 
>> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
>> paths or something else? The more this thread goes on the more confused I 
>> get about why Swift would have this issue while it doesn’t appear to be one 
>> for Obj-C. If an enum adds a case now, I don’t have to care until I 
>> recompile using the new SDK. Is the intention for Swift to be different in 
>> this regard?
>> 
>> 
>> 
>> Jon Shier
>> 
>>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
  wrote:
 
 Is it hard to imagine that most everyone can get what they want and keep 
 the syntax clean and streamlined at the same time? Without any "@" signs 
 or other compiler hints?
>>> 
>>> For what it's worth, the original version of the proposal started with a 
>>> modifier (a context-sensitive keyword, like 'final'), but the core team 
>>> felt that there were a lot of modifiers in the language already, and this 
>>> didn't meet the bar.
>>> 
>>> 
> "Rather, we are how to enable the vendor of a nonexhaustive enum to add 
> new cases without breaking binaries compiled against previous versions"
 
 When an enum changes, and the change causes the code to break, the user 
 can be presented with migration options from an automated IDE tool. In 
 what specific way does this not solve the issue about having to upgrade 
 your code when using someone else's code library? This very notion implies 
 your disgruntled about doing work when things are upgraded, is that really 
 what this fuss is all about?
 
 A well written language interpreter and auto-tooling IDE would not need 
 hints embedded in the code syntax itself. Migration hints from version to 
 version should not be a part of either the past or future version of the 
 code library.
>>> 
>>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>>> because if there's a new enum case, it's unclear what you want to do with 
>>> it. If you're handling errors, it's not obvious that the way you've handled 
>>> any of the other errors is appropriate. In the (admittedly controversial) 
>>> SKPaymentTransactionState case, none of the existing code would be 
>>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>>> StoreKit provide "template" code that would be appropriate to the client 
>>> app.
>>> 
>>> 
>>> In any case, though, the key point on this particular quoted sentence is 
>>> "without breaking binaries". Any such change must be valid without 
>>> recompilation, and indeed without any intervention from the developer or an 
>>> IDE, because that's what happens when the user updates their OS.
>>> 
>>> Jordan
>>> 
>>> 
>>> 
 
 ...
 
 I don't expect the community to agree on language grammar, but the common 
 sense here on how to achieve the intended goals seems to be out of wack.
 
 If someone can present a clear logical statement as to how an automated 
 migration tool behind the scenes in the IDE to handle all your versioning 
 worries, does not make this whole discussion about adding more convoluted 
 syntax additions irrelevant, I'd love to hear it.
 
 ___
 
 Sincerely,
 Jason
 
 
 
 
 
 
> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via 

Re: [swift-evolution] Renaming SwiftObject

[Saagar Jha via swift-evolution]

Just my 2¢, from the point of view of someone runs into SwiftObject frequently: 
I’d really appreciate it if this class had “Swift” in it’s name. At first 
glance, it’s name in mangled form (“_TtCs7_Object”) gives no indication as to 
where it’s from. Obviously it’s not a “pure” Objective-C object, but it’s not 
clear that it’s a Swift object either–maybe it’s C++? Saagar’s cool new 
language that also does name mangling? Who knows. I guess “_T” is kind of 
enough to figure it out, but since you’re changing the name anyways it would be 
great if it was something that reduced my cognitive overload, like 
Swift._SwiftObject.

If you’re going to expose this to Swift as well, a similar argument applies: 
from it’s name, it’s not clear that it’s part of Objective-C interop. I’m not 
sure if this is visible to Swift programmers, and if it isn’t this isn’t an 
issue, but in the case that it is Swift._Object looks more like a private 
implementation detail of a base class akin to NSObject in Objective-C or Object 
in Java than a compatibility shim with Objective-C.

Saagar Jha

> On Jan 4, 2018, at 19:10, Greg Parker via swift-evolution 
>  wrote:
> 
> SwiftObject is an Objective-C class that is the base class of all "pure 
> Swift" class types. It needs to be renamed for the Swift stable ABI in order 
> to avoid ObjC class name collisions between the stable ABI's Swift runtime 
> and the runtime embedded into existing Swift apps.
> 
> I suggest `Swift._Object`, mangled as _TtCs7_Object like other Swift ObjC 
> class names. 
> 
> Any comments?
> 
> https://github.com/apple/swift/pull/13748 
> 
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] [Review] SE 0192 - Non-Exhaustive Enums

[Javier Soto via swift-evolution]

This is very much an issue in Obj-C today. If you have an NS_ENUM defined
with cases A, B, and C, this switch is correct:

int foo;
swith (e) {
case A: foo = 0; break;
case B: foo = 1; break;
case C: foo = 2; break;
}

(Note the lack of a default case)

If that enum is defined in a framework and it changes after the app is
compiled (like it's the case with Apple frameworks), then that code
produces no warning, yet the foo variable will have a garbage value
(undefined behavior, but as far as the compiler can tell at compile time
your code is fine)

Adding a default clause to that switch has the downside of not getting
warnings for new added cases, like has been discussed before, which is very
useful.
On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> At this point I think it might be useful to outline how binary
> compatibility works for Objective-C on Apple platforms right now. As an app
> developer I’m not intimately familiar with what happens when you run an app
> compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to
> call old code paths or something else? The more this thread goes on the
> more confused I get about why Swift would have this issue while it doesn’t
> appear to be one for Obj-C. If an enum adds a case now, I don’t have to
> care until I recompile using the new SDK. Is the intention for Swift to be
> different in this regard?
>
>
>
> Jon Shier
>
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is it hard to imagine that most everyone can get what they want and keep
> the syntax clean and streamlined at the same time? Without any "@" signs or
> other compiler hints?
>
>
> For what it's worth, the original version of the proposal started with a
> modifier (a context-sensitive keyword, like 'final'), but the core team
> felt that there were a lot of modifiers in the language already, and this
> didn't meet the bar.
>
>
> "Rather, we are how to enable the vendor of a nonexhaustive enum to add
>> new cases without breaking binaries compiled against previous versions"
>
>
> When an enum changes, and the change causes the code to break, the user
> can be presented with migration options from an automated IDE tool. In what
> specific way does this not solve the issue about having to upgrade your
> code when using someone else's code library? This very notion implies your
> disgruntled about doing work when things are upgraded, is that really what
> this fuss is all about?
>
> A well written language interpreter and auto-tooling IDE would not need
> hints embedded in the code syntax itself. Migration hints from version to
> version should not be a part of either the past or future version of the
> code library.
>
>
> Thanks for bringing this up! Unfortunately, it falls down in practice,
> because if there's a new enum case, *it's unclear what you want to do
> with it.* If you're handling errors, it's not obvious that the way you've
> handled any of the *other* errors is appropriate. In the (admittedly
> controversial) SKPaymentTransactionState case, none of the existing code
> would be appropriate to handle the newly-introduced "deferred" case, and
> nor could StoreKit provide "template" code that would be appropriate to the
> client app.
>
>
> In any case, though, the key point on this particular quoted sentence is
> "without breaking *binaries"*. Any such change must be valid *without* 
> recompilation,
> and indeed without any intervention from the developer or an IDE, because
> that's what happens when the user updates their OS.
>
> Jordan
>
>
>
>
> ...
>
> I don't expect the community to agree on language grammar, but the common
> sense here on how to achieve the intended goals seems to be out of wack.
>
> If someone can present a clear logical statement as to how an automated
> migration tool behind the scenes in the IDE to handle all your versioning
> worries, does not make this whole discussion about adding more convoluted
> syntax additions irrelevant, I'd love to hear it.
>
> ___
>
> Sincerely,
> Jason
>
>
>
>
>
>
> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:
>
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I think this whole thing has been unnecessarily convoluted. As a result,
>>> the majority of the replies are rabbit holes.
>>>
>>> In my opinion, the true root of the concept in question is as follows:
>>>
>>> *A list of something is desired:*
>>> 1 - Pancake
>>> 2 - Waffle
>>> 3 - Juice
>>>
>>> *Developer wishes to be able to:*
>>> *A)* Add new things to the list of choices in the future as they come
>>> up with new ideas
>>> *B)* Sometimes select one of the choices to be chosen as the normal
>>> choice if no choice is made by the user
>>>
>>> A 

[swift-evolution] Concurrency: Expressive, Easy and Safe.

[Alex Lynch via swift-evolution]

Hey All,

I want to share something I’ve been working on. I know this isn't strictly
"swift-evolution" content, but I think it relates heavily to the ongoing
conversation around concurrency features in the language (such as
async/await).  If you're interested in such topics would you mind taking a
look?


HoneyBee.start { root in
root.setErrorHandler(handleError)
.chain(fetchNewMovieTitle)
.branch { stem in
stem.chain(fetchReviews)
.chain(averageReviews)
+
stem.chain(fetchComments)
.chain(countComments)
}
.setBlockPerformer(DispatchQueue.main)
.chain(updateUI)
}
func handleError(_ error: Error) {}
func fetchNewMovieTitle(completion: (String?, Error?) -> Void) {}
func fetchReviews(for movieTitle: String, completion:
(FailableResult<[String]>) -> Void) {}
func averageReviews(_ reviews: [String]) throws -> Int { return
reviews.count }
func fetchComments(for movieTitle: String, completion: (([String]?, Error?)
-> Void)?) {}
func countComments(_ comments: [String]) -> Int { return comments.count }
func updateUI(withAverageReview: Int, commentsCount: Int) {}


(Yes that compiles. Much thanks to the Language Team.)

HoneyBee makes concurrent programming expressive, easy and safe. The above
recipe lexically matches the flow of execution.
First `fetchNewMovieTitle` is invoked. Then `fetchReviews` and
`fetchComments` are invoked in parallel each receiving the result of
`fetchNewMovieTitle`. `averageReviews` is invoked after `fetchReviews`
finishes and `countComments` is invoked after `fetchComments`. The results
of `averageReviews` and `countComments` are combined and forwarded to
`updateUI`, which is invoked on the main queue.


HoneyBee.start(on: DispatchQueue.main) { root in
root.setErrorHandler(handleError)
.chain(fetchNewMovieTitle)
.chain(fetchReviews)
.map { elem in // parallel map
elem.chain(\.count)// Keypath access
}
.filter { elem in // parallel filtering
elem.chain(isNonTrivial)
}
.reduce { pair in // parallel "pyramid" reduce
pair.chain(+) // operator access
}
.chain(updateUI)
}
func handleError(_ error: Error) {}
func fetchNewMovieTitle(completion: (String?, Error?) -> Void) {}
func fetchReviews(for movieTitle: String, completion:
(FailableResult<[String]>) -> Void) {}
func isNonTrivial(_ int: Int, completion: (Bool) -> Void) {}
func updateUI(withTotalWordsInNonTrivialReviews: Int) {}


The above recipe demonstrates use of parallel map, filter and reduce. The
entire recipe is run on the main queue.


struct Image {}
func processImageData(completionBlock: @escaping (Image?, Error?) -> Void) {
func loadWebResource(named name: String, completion: (Data?, Error?) ->
Void) {}
func decodeImage(dataProfile: Data, image: Data) throws -> Image {
return Image() }
func dewarpAndCleanupImage(_ image: Image, completion: (Image?, Error?)
-> Void) {}

HoneyBee.start { root in
root.setErrorHandler { completionBlock(nil, $0) }
.branch { stem -> Link<(Data,Data)> in
stem.chain(loadWebResource =<< "dataprofile.txt")
+
stem.chain(loadWebResource =<< "imagedata.dat")
}
.chain(decodeImage)
.chain(dewarpAndCleanupImage)
.chain{ completionBlock($0, nil) }
}
}

The above recipe is a translation of the now famous clatner "pyramid of
doom" .
Note that the HoneyBee form allows us to effortlessly parallelize the two
data fetches.


HoneyBee has many more features including:

* Total of 34 chain signatures
* Limit to globally control accesses to a resource
* Retry to re-attempt subchains that are known to have transient failures
* Helpful diagnostics when things go wrong

See the full documentation at HoneyBee.link

Thanks for your time. Looking forward to your feedback,

Alex
___
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

[Saagar Jha via swift-evolution]

(Disclaimer: I’m no expert in this, and I know there are people in this list 
that are, so if there’s anything wrong please feel free to step in and correct 
me)

As far as I’m aware, Apple’s frameworks check which version of the framework 
you linked with at runtime (for UIKit, I believe this function is 
UIApplicationLinkedOnOrAfter) and modify their behavior to match. For example, 
if this function shows your application was linked with the iOS 6 SDK you’d get 
the old skeuomorphic UI instead of the “flatter”, newer iOS 7-style controls. 
What this means is every library actually keeps old implementations around in 
addition to the newer ones and picks the necessary one at runtime, so binary 
compatibility boils down to things like “don't change the memory layout of 
classes” rather than “don’t change the behavior of your program”.

Saagar Jha

> On Jan 5, 2018, at 19:11, Jon Shier via swift-evolution 
>  wrote:
> 
> At this point I think it might be useful to outline how binary compatibility 
> works for Objective-C on Apple platforms right now. As an app developer I’m 
> not intimately familiar with what happens when you run an app compiled with 
> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
> paths or something else? The more this thread goes on the more confused I get 
> about why Swift would have this issue while it doesn’t appear to be one for 
> Obj-C. If an enum adds a case now, I don’t have to care until I recompile 
> using the new SDK. Is the intention for Swift to be different in this regard?
> 
> 
> 
> Jon Shier
> 
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
>>> > wrote:
>>> 
>>> Is it hard to imagine that most everyone can get what they want and keep 
>>> the syntax clean and streamlined at the same time? Without any "@" signs or 
>>> other compiler hints?
>> 
>> For what it's worth, the original version of the proposal started with a 
>> modifier (a context-sensitive keyword, like 'final'), but the core team felt 
>> that there were a lot of modifiers in the language already, and this didn't 
>> meet the bar.
>> 
>> 
>>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add new 
>>> cases without breaking binaries compiled against previous versions"
>>> 
>>> When an enum changes, and the change causes the code to break, the user can 
>>> be presented with migration options from an automated IDE tool. In what 
>>> specific way does this not solve the issue about having to upgrade your 
>>> code when using someone else's code library? This very notion implies your 
>>> disgruntled about doing work when things are upgraded, is that really what 
>>> this fuss is all about?
>>> 
>>> A well written language interpreter and auto-tooling IDE would not need 
>>> hints embedded in the code syntax itself. Migration hints from version to 
>>> version should not be a part of either the past or future version of the 
>>> code library.
>> 
>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>> because if there's a new enum case, it's unclear what you want to do with 
>> it. If you're handling errors, it's not obvious that the way you've handled 
>> any of the other errors is appropriate. In the (admittedly controversial) 
>> SKPaymentTransactionState case, none of the existing code would be 
>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>> StoreKit provide "template" code that would be appropriate to the client app.
>> 
>> 
>> In any case, though, the key point on this particular quoted sentence is 
>> "without breaking binaries". Any such change must be valid without 
>> recompilation, and indeed without any intervention from the developer or an 
>> IDE, because that's what happens when the user updates their OS.
>> 
>> Jordan
>> 
>> 
>> 
>>> 
>>> ...
>>> 
>>> I don't expect the community to agree on language grammar, but the common 
>>> sense here on how to achieve the intended goals seems to be out of wack.
>>> 
>>> If someone can present a clear logical statement as to how an automated 
>>> migration tool behind the scenes in the IDE to handle all your versioning 
>>> worries, does not make this whole discussion about adding more convoluted 
>>> syntax additions irrelevant, I'd love to hear it.
>>> 
>>> ___
>>> 
>>> Sincerely,
>>> Jason
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu >> > wrote:
>>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>> > wrote:
>>> I think this whole thing has been unnecessarily convoluted. As a result, 
>>> the majority of the replies are 

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

[Jason Merchant via swift-evolution]

There are a number of things being talked about in this thread, all of
which are solved by proper automated IDE tooling.

Javier, In my opinion the situation you've described is based on how
overall nil is handled by the language parser before it generates LLVM IR.

A smart compiler would know what to do here without any changes to the
language syntax. (Having implemented a similar language parser for LLVM IR,
I can say for certain there is no excuse for the ugly syntax choices that
Swift has been making, and it appears to me the result of laziness and bad
design choices)

I solved this without setting a value before the switch/case statements and
without forcing a default clause to be written. No doubt, it has been clear
that these things appear troubling because of the incorrect design choices
and approach to the underlying problem.

I will present another situation outside of the realm of enums in which
Swift syntax has been made incorrect syntax choices in the handling of nil.

The most obvious is optionals. There are several things wrong with the
swift implementation of optionals:

A: When an object is nil, swift syntax itself changes to try to protect the
user. This results in extra code the developer has to type, even if they
program in genres in which optional situations are irrelevant. (Forcing the
user to unwrap optionals with things like "if let" and "guard" is ugly,
bloated, and unnecessary) In my implementation I have seen that there is no
need for optionals to be written like this in the syntax.

B: The symbols "?" and "!" are littered throughout code needlessly as *compiler
hints*. Meaning the swift parser programmer team was essentially too lazy
to implement what I'm describing and sacrificed the syntax of the language
to avoid writing a parser that would be able to know if something was set
or nil without adding extra garbage to the syntax. Again in my
implementation, I have verified that this can be done and in fact if done
correctly, the resulting* compile time is faster* than the swift compiler,
and the code is cleaner.

What is happening in this thread is that there are core underlying
philosophies that the swift design has adopted which are incorrect
approaches to big picture problems. As a result of swift making these big
picture mistakes, there arise a plethora of these other troubles that come
as domino effects in circumstances here and there. This is why there is a
lot of talk about patching the syntax here or there, and forcing things to
be written, and then down wind of this trail of derailed logic, there arise
a number of people debating what grammar to use for something that
shouldn't be written in the first place. If the big picture problem is
solved, the majority of these discussions are mute.

If Swift can accept that these choices were incorrect, we can cleanup the
syntax and rewrite the parser within an impressively short time as I've
seen myself. However, this requires the agreement of those involved, and
based on this thread and the fact that this line of derailed logic has gone
on for several years, means that the likely response to what I'm suggesting
is one of "That sounds like a lot of work to change, and I already spent a
lot of time and effort making it like this" - Laziness is no excuse for
sticking to bad choices made in the past and causing more bad syntax
choices to be made in the present. If we are truly going to make swift the
dominant language for the future, then we have to adopt a different
attitude toward rewriting design flaws as a community.

We can't always see into the future and know if a choice will be good or
bad, but when we are far enough along the trail to see that the choices
swift made in the past and are a core part of the language, are in fact the
root of the problem, rather than clinging to backward compatibility of a
clearly misguided architecture, *we should do the wise thing and rewrite
the foundation of the language to be built on solid concepts of what we
have learned from the mistakes.*


___

Sincerely,
Jason




On Sat, Jan 6, 2018 at 8:07 PM, Javier Soto  wrote:

> Why isn't that a problem today? Like I showed in that example, that's
> undefined behavior and will potentially result in a bug (or even a crash if
> instead of an int you end up with an unexpected nil pointer)
>
> On Sat, Jan 6, 2018 at 4:47 PM Jon Shier  wrote:
>
>> Which isn’t a problem right now, AFAICT. Apps compiled under older SDKs
>> continue to work fine (sometimes better than when compiled under the new
>> SDK, as the older one avoids new bugs). My question is about how that
>> compatibility is accomplished today and how and why the Obj-C and Swift
>> cases are apparently different here.
>>
>>
>>
>> Jon
>>
>> On Jan 6, 2018, at 6:12 PM, Javier Soto  wrote:
>>
>> What doesn't happen today? The issue is not when they ship a new SDK:
>> When rebuilding your app against it, you'll get a 

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

[Jean-Daniel via swift-evolution]

> Le 6 janv. 2018 à 04:11, Jon Shier via swift-evolution 
>  a écrit :
> 
> At this point I think it might be useful to outline how binary compatibility 
> works for Objective-C on Apple platforms right now. As an app developer I’m 
> not intimately familiar with what happens when you run an app compiled with 
> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
> paths or something else? The more this thread goes on the more confused I get 
> about why Swift would have this issue while it doesn’t appear to be one for 
> Obj-C. If an enum adds a case now, I don’t have to care until I recompile 
> using the new SDK. Is the intention for Swift to be different in this regard?
> 

Obj-C does not mandate that you have to handle all cases in an enum. Swift 
does. In Obj-C, when you switch over an unhandled value, the code just flow 
after the switch and continue executing. Your code may be silently buggy (as it 
misses a case), but it does not crash.

In Swift, if you swift over an unhandled case, the program abort execution. 
This is part of the Swift safety model where the language prefers to crash soon 
than continuing with potentially broken assumptions and crashing later at a 
completely unrelated point (which make it very hard to find the root cause of 
the crash).



> 
> 
> Jon Shier
> 
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
>>> > wrote:
>>> 
>>> Is it hard to imagine that most everyone can get what they want and keep 
>>> the syntax clean and streamlined at the same time? Without any "@" signs or 
>>> other compiler hints?
>> 
>> For what it's worth, the original version of the proposal started with a 
>> modifier (a context-sensitive keyword, like 'final'), but the core team felt 
>> that there were a lot of modifiers in the language already, and this didn't 
>> meet the bar.
>> 
>> 
>>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add new 
>>> cases without breaking binaries compiled against previous versions"
>>> 
>>> When an enum changes, and the change causes the code to break, the user can 
>>> be presented with migration options from an automated IDE tool. In what 
>>> specific way does this not solve the issue about having to upgrade your 
>>> code when using someone else's code library? This very notion implies your 
>>> disgruntled about doing work when things are upgraded, is that really what 
>>> this fuss is all about?
>>> 
>>> A well written language interpreter and auto-tooling IDE would not need 
>>> hints embedded in the code syntax itself. Migration hints from version to 
>>> version should not be a part of either the past or future version of the 
>>> code library.
>> 
>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>> because if there's a new enum case, it's unclear what you want to do with 
>> it. If you're handling errors, it's not obvious that the way you've handled 
>> any of the other errors is appropriate. In the (admittedly controversial) 
>> SKPaymentTransactionState case, none of the existing code would be 
>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>> StoreKit provide "template" code that would be appropriate to the client app.
>> 
>> 
>> In any case, though, the key point on this particular quoted sentence is 
>> "without breaking binaries". Any such change must be valid without 
>> recompilation, and indeed without any intervention from the developer or an 
>> IDE, because that's what happens when the user updates their OS.
>> 
>> Jordan
>> 
>> 
>> 
>>> 
>>> ...
>>> 
>>> I don't expect the community to agree on language grammar, but the common 
>>> sense here on how to achieve the intended goals seems to be out of wack.
>>> 
>>> If someone can present a clear logical statement as to how an automated 
>>> migration tool behind the scenes in the IDE to handle all your versioning 
>>> worries, does not make this whole discussion about adding more convoluted 
>>> syntax additions irrelevant, I'd love to hear it.
>>> 
>>> ___
>>> 
>>> Sincerely,
>>> Jason
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu >> > wrote:
>>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>> > wrote:
>>> I think this whole thing has been unnecessarily convoluted. As a result, 
>>> the majority of the replies are rabbit holes.
>>> 
>>> In my opinion, the true root of the concept in question is as follows:
>>> 
>>> A list of something is desired:
>>> 1 - Pancake
>>> 2 - Waffle
>>> 3 - Juice
>>> 
>>> Developer wishes to be able to:
>>> A) Add new things to the 

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

[Gregg Wonderly via swift-evolution]

In some dictionary implementations, key-value pairs are added with an add() 
method which disallows duplicate keys to be inserted with a runtime exception.  
Providing an additional method of set() allows for the ability to ignore 
duplicate keys so that it feels more like dict[key] = value.  It might be 
interesting to provide this as a selectable behavior within an additional 
constructor's arguments.  

Dictionary(allowDuplicate: true, pairs: [("z", 1), ("z", 2), ("z", 3), ("z", 
4)]) so that the dictionary behavior remains in line with the compile time 
checks.

Gregg

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