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

[Antoine Cœur via swift-evolution]

I read:

Ma.allValues.count   // returns 8

But that sounds like all values will need to be computed in order to get
the count, so some people will be tempted to write:

Ma.lazy.allValues.count   // returns 8

To avoid that, it may be nicer to make enum `Ma` behaves like a collection
directly, so that we can write:

Ma.count   // returns 8
Ma.map { return "\($0)" }   // returns a stringification

A little bit like what was done on String when we dropped the requirement
of writing `.characters`, it would be perfect to directly drop the
requirement of writing `.allValues`.

Le mer. 10 janv. 2018 à 14:40, Chris Lattner via swift-evolution <
swift-evolution@swift.org> a écrit :

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> > My objection to the "ValueEnumerable" design--especially in its
> generalized form here (versus "CaseEnumerable")--is that the protocol's
> semantics (and, we'll recall, protocols in Swift must offer semantics that
> make possible useful generic algorithms) are so broad as to be little more
> than essentially what it means to be a type.
>
> Thank you for writing this up Xiaodi.  I completely agree with you that
> “CaseEnumerable” is a better name for this: it is more specific and
> purposeful and make it more clear what the purpose and scope is.
>
> Your later suggestion of “Enumerable” seems to broad and potentially
> confusing to me.  Tying it to the things that are being enumerated (enum
> cases) seems more purposeful.
>
>
> > Brent just wrote that he might later propose to extend `ValueEnumerable`
> to `Bool` and `Optional`,
>
> To be fair, Optional *is* an enum, and Bool really should be (we only
> switched it to its current design for internal optimizer reasons).
>
> Making Bool conform to this would require manual conformance - if we were
> motivated to give Bool all the enum-like facilities (including a Bool.true
> and Bool.false member) then having it conform seems conceptually fine to me.
>
> I would personally object to attempts to make optional conform though. One
> of its cases has an associated value and this isn’t something we should
> support IMO.  I believe that this is one of the roots of your objection.
>
> -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] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

Saagar Jha

> On Jan 9, 2018, at 22:02, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution 
> > wrote:
>> Good afternoon,
> 
> Hi Connor,
> 
> Huge +1 for this proposal, I’m thrilled you’re cleaning this up.  Couple of 
> detail questions:
> 
>>  
>> 
>> Detailed design
>> 
>> To provide a more flexible API, we propose deprecating and ultimately 
>> removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable 
>> protocol in favor of a simpler design. Instead, we propose introducing a 
>> protocol which just provides the ability to return an Any (or nil) that 
>> serves as a stand-in for the instance being logged:
>> 
> 
> What is the use-case for a type conforming to this protocol but returning 
> nil?  If there is a use case for that, why not have such an implementation 
> return “self” instead?
> 
> In short, can we change playgroundRepresentation to return Any instead of 
> Any?.  Among other things, doing so could ease the case of playground 
> formatting Optional itself, which should presumably get a conditional 
> conformance to this.  :-)

I believe the rationale behind this was to provide a way to “opt-out” of a 
customized representation, although now that I think about it, what exactly 
does the default mean? In particular, what happens in this case?

// I’m not sure how this will be implemented: possibly UIView won’t conform to 
CustomPlaygroundRepresentable and the first class inheriting from it will do 
this?
// Either way, it shouldn’t really affect my example since this will just mean 
that FooView will implement it instead
class UIView: CustomPlaygroundRepresentable {
var playgroundRepresentation: Any? {
return self // I assume this is done somewhere in the bowels of 
PlaygroundSupport or whatever
}
}

class FooView: UIView {
override var playgroundRepresentation: Any? {
return “foo”
}
}

class BarView: FooView {
override var playgroundRepresentation: Any? {
return nil
}
}

In this case, what’s the default? UIView’s implementation, or that of the 
immediate parent (FooView’s)?

> 
> 
>> /// Implementors of `CustomPlaygroundRepresentable` may return a value of 
>> one of
>> /// the above types to also receive a specialized log representation.
>> /// Implementors may also return any other type, and playground logging will
>> /// generated structured logging for the returned value.
>> public protocol CustomPlaygroundRepresentable {
> On the naming bikeshed, the closest analog to this feature is 
> CustomStringConvertible, which is used when a type wants to customize the 
> default conversion to string.  As such, have you considered 
> CustomPlaygroundConvertible for consistency with it?
> 
> The only prior art for the word “Representable” in the standard library is 
> RawRepresentable, which is quite a different concept.
> 
>>   /// Returns the custom playground representation for this instance, or nil 
>> if
>>   /// the default representation should be used.
>>   ///
>>   /// If this type has value semantics, the instance returned should be
>>   /// unaffected by subsequent mutations if possible.
>>   var playgroundRepresentation: Any? { get }
> Again to align with CustomStringConvertible which has a ‘description’ member, 
> it might make sense to name this member “playgroundDescription”.
> 
> Thank you again for pushing this forward, this will be much cleaner!
> 
> -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] Handling unknown cases in enums [RE: SE-0192]

[Antoine Cœur via swift-evolution]

And what about, as an alternative:

case (_, #unknown): …  matches any int and any unknown enum case ...
case _:  … matches anything ...

Then it clearly goes the "pattern matching" way.


Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution <
swift-evolution@swift.org> a écrit :

> On Jan 9, 2018, at 4:46 PM, Jordan Rose  wrote:
>
> Thanks for writing this up, Chris! I addressed the idea of making this an
> arbitrary pattern in the revised proposal
> ,
> and the idea of not matching known cases in a "considered alternative"
> ,
> but in short:
>
> - Matching in arbitrary pattern positions is harder to implement and
> harder to produce good diagnostics for. (Specifically, the former comes
> from having to actually check the existing cases in the generated code
> rather than just having an "else" branch.) I'm not inherently opposed to it
> if we can all agree on what it means, but I don't think I have time to
> implement it for Swift 5, so I'm not including it in the proposal.
>
>
> I’m not sure what you’re saying here.  This does slot directly into the
> existing pattern design: it is just a new terminal pattern node.  Are you
> saying the SILGen/IRGen is more difficult and therefore you’re not
> interested in doing it even if it is the better design?
>
> If that is the case, then the conservatively correct thing to do (in my
> opinion) is to add no feature here: no “unknown case:” and no “case
> #unknown:’.
>
> Alternatively are you saying that you intend to support only the “case
> #unknown:” form exactly, but not the recursive cases?
>
> - Matching known cases is a feature, not a limitation, to avoid existing
> code changing meaning when you recompile. I'll admit that's not the
> strongest motivation, though, since other things can change the meaning of
> existing code when you recompile already.
>
>
> I’m not sure I understand this.
>
> The whole motivation for this feature is to notify people if they are not
> handling a “newly known” case.  If they don’t care about this, they can
> just use default.
>
> - FWIW I can't actually think of a use case for using this with `if case`
> or anything else. I'm not against it, but I don't know why you would ever
> do it, just like I don't know why you would mix `case #unknown` with
> `default` when matching against a single value.
>
>
> Brent gave a simple example down thread.  That said, I’m more concerned
> about keeping pattern matching simple and composable than I am about
> particular use cases (I agree the top level case in a switch on enum is the
> disproportionately important case).
>
> At some point we will hopefully extend pattern matching to support regexes
> and other things, we want to keep the design consistent.
>
> That said, it sounds like people are happier with `case #unknown` than
> `unknown case`, and that leaves things a little more consistent if we ever
> do expand it to other pattern positions, so I'll change the proposal
> revision to use that spelling. (And if anyone comes up with a nicer
> spelling, great!)
>
>
> Thanks!
>
> -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] [Review] SE-0194: Derived Collection of Enum Cases

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution 
 wrote:
> My objection to the "ValueEnumerable" design--especially in its generalized 
> form here (versus "CaseEnumerable")--is that the protocol's semantics (and, 
> we'll recall, protocols in Swift must offer semantics that make possible 
> useful generic algorithms) are so broad as to be little more than essentially 
> what it means to be a type.

Thank you for writing this up Xiaodi.  I completely agree with you that 
“CaseEnumerable” is a better name for this: it is more specific and purposeful 
and make it more clear what the purpose and scope is.

Your later suggestion of “Enumerable” seems to broad and potentially confusing 
to me.  Tying it to the things that are being enumerated (enum cases) seems 
more purposeful.


> Brent just wrote that he might later propose to extend `ValueEnumerable` to 
> `Bool` and `Optional`,

To be fair, Optional *is* an enum, and Bool really should be (we only switched 
it to its current design for internal optimizer reasons).  

Making Bool conform to this would require manual conformance - if we were 
motivated to give Bool all the enum-like facilities (including a Bool.true and 
Bool.false member) then having it conform seems conceptually fine to me.

I would personally object to attempts to make optional conform though. One of 
its cases has an associated value and this isn’t something we should support 
IMO.  I believe that this is one of the roots of your objection.

-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]

Disclaimer: I’m reordering your comments below to suit my nefarious purposes: 
:-)

On Jan 9, 2018, at 3:48 PM, Ben Cohen  wrote:
>> More to the point though, this seems like an implementation detail of 
>> Mirrors.  What is the plan for Mirrors + ABI stability?
>> 
> 
> Absent a proposal to change them to something better (and I’m not aware of 
> one pending), the plan is they are what they are, at least the public API of 
> Swift.Mirror. I would guess this whole area is a candidate to be overhauled 
> significantly at some point in the post-Swift 5 future with some more 
> fully-fledged reflection system, but there is little chance of this happening 
> before ABI stability, and interim tinkering doesn’t seem worthwhile to me.

Ok, I understand that (among all the other things going on that are clearly 
more important) revamping this is probably not the highest priority thing to 
do.  That said, it would be really unfortunate to carry around these 
“suboptimal” APIs forever, particularly given how marginal they are (as in, not 
widely used).  I’m sure that there are other examples beyond these that are 
similarly unfortunate.

Given that, I have a meta question for you: have you considered an approach 
where you take the Swift standard library and split it into two conceptual 
pieces:

1) The "ABI stable” subset of the library that gets burned into the OS.
2) The “ABI unstable” subset, which gets statically linked into apps, just like 
the Swift 4 library used to?

Given that “import Swift” is implicit anyway, you could just have the compiler 
implicitly import *both* of these modules.  


The point of doing this is that it gives you a very general and low friction 
way to handle compatibility gunk.  In addition to putting obscure stuff like 
Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
now get the ability to put the various deprecated forwarding functions in this 
module as well, avoiding them becoming part of the ABI.

The nice thing about this is that only people who use these things would have 
to pay the cost, and you can directly message this by deprecating all the stuff 
in it.  Think about it as an overlay for the Swift standard library :-)

>> +1 for renaming it to something that isn’t super confusing, but +100 for 
>> removing it outright.
>> 
>> Rationale: if we didn’t have this functionality in the stdlib today, we 
>> would not consider adding it.  It doesn’t meet the bar we’ve set for what is 
>> in the standard library.  It only exists there by historical accident.  The 
>> Mirror API was not carefully considered.
>> 
> 
> Personally, I feel like this argument for removal as past its use-by date. It 
> was a good reason for Swift 3, tenuous for 4 and should be ruled out for 5, 
> since the source stability bar has been raised since. Like I said, IMO the 
> criteria should now be “active harm”. I also don’t think searches of GitHub 
> etc are sufficient justification, except when combined with the active-harm 
> argument. I also don’t think the origin story of the type – whether 
> accidental or intentional – is relevant to the decision of what to do with it 
> now. It exists and people can legitimately use it for their own purposes 
> independent of mirrors.

I’m generally in agreement with you, but in this specific case, I seriously 
doubt people are using this.  All rules are malleable in the right 
circumstances.

More importantly though, if we had a meta design that allowed to gracefully 
phase this sort of thing out (without it becoming part of ABI under any name) 
there becomes very little cost to leaving it around in the “abi unstable” 
library for…. ever if need be.  Given that, I would have much less objection to 
keeping it around.

-Chris

___
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

[Xiaodi Wu via swift-evolution]

On Mon, Jan 8, 2018 at 1:02 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> 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?
>
> I continue to have concerns about this proposal, and I'm gravely and very
bitterly disappointed that the concerns have not even been acknowledged in
the Alternatives section, which is in my view the minimum action that an
author should take when points are raised during a pitch phase, even (and
especially) when the author disagrees, along with a cogent write-up of why
the proposed design is superior in the author's view to the alternative. In
this case, the proposal authors write:

  "The community has not raised any solutions whose APIs differ
significantly from this proposal, except for solutions which provide
strictly more functionality."

This is false, as I have offered a solution in the past whose API differs
entirely from this proposal, and which provides strictly a subset of the
functionality which goes to the core of the issue at stake.

In the past, I have stated on this list that once a statement has been
made, it should not be repeated simply because one is disappointed in the
outcome, as one should operate on the presumption that all actors proceed
in good faith and have already considered the statement. Here, however,
given that the write-up literally denies the existence of what I have
already written, I will restate my concerns here once again. I would expect
that on revision the authors will properly record a considered reply.

My objection to the "ValueEnumerable" design--especially in its generalized
form here (versus "CaseEnumerable")--is that the protocol's semantics (and,
we'll recall, protocols in Swift must offer semantics that make possible
useful generic algorithms) are so broad as to be little more than
essentially what it means to be a type.

Earlier in this thread (or was it in the companion one?), another community
member suggested that if `allValues` were to conform to `Sequence` instead
of `Collection`, then even types that have an infinite number of possible
values could conform to `ValueEnumerable`. Here's the rub: the definition
of a type, or at least one of them, _is_ precisely the set of all possible
values of a variable. If unconstrained by finiteness, then *all types*
would meet the semantic requirements of `ValueEnumerable`.

As proposed, "`ValueEnumerable`...indicate[s] that a type has a finite,
enumerable set of values"; now, we have the constraint that the type merely
must have an upper bound in terms of memory referenced. Brent just wrote
that he might later propose to extend `ValueEnumerable` to `Bool` and
`Optional`, but theoretically and practically speaking it appears that it
can correctly be extended to any type in the standard library that is not a
`Sequence`, and with minimal effort even `Collection` types of fixed size
(e.g., CollectionOfOne with the right constraints as to the generic type
T).

Put another way, there are two issues with generalizing the very specific
use case of "I want to know all the cases of an enum" to what is proposed
here in terms of a protocol. First, "ValueEnumerable"-ness is neither
universal to all enums (as those with associated types, indirect cases
(think of all those tutorials about linked lists implemented as Swift
enums), etc., are clearly not enumerable) nor unique as a property of
enums, yet this proposal first makes a large generalization of the proposed
protocol's semantics when the stated motivation is only about enums, then
proceeds only to implement protocol conformance for enums. Second, the
collection of all values is properly just the type and not a property of
the type, for the reasons outlined above.

So far, the justification I have heard for ignoring this objection is that
(a) lots of people want the 

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 8, 2018, at 3:23 PM, Gregg Wonderly via swift-evolution 
>  wrote:
> 
> 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?

Having only the values allows you to do some nice higher-order things, like:

let histogram = Dictionary(values.map { ($0, 1) }, uniquingValuesWith: 
+)

In other words, the same functions you could use with `reduce` can be used with 
`init(_:uniquingValuesWith:)`. If the function took a third parameter, we would 
lose this property.

There's a bunch of very reasonable things you can't do with 
`Dictionary(_:uniquingValuesWith:)`; for instance, you can't cause the 
initializer to fail by returning `nil`, only by throwing an error. Supporting 
these features would either complicate cases where you don't need them, or 
require us to provide another overload. Given that 
`Dictionary(_:uniquingValuesWith:)` and friends are just conveniences, and 
reimplementing them requires only a few lines of straightforward code, it's 
just not worth supporting every plausible variant.

(For what it's worth, the Swift Evolution proposal which added this 
initializer, [SE-0165 Dictionary & Set 
Enhancements](https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md),
 touches on some of these issues. A big part of a proposal's role is to 
document the reasons for Swift's designs; if you ever wonder why something in 
Swift is designed the way it is, the feature's evolution proposal is a good 
place to start.)

-- 
Brent Royal-Gordon
Architechies

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

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

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 4:46 PM, Jordan Rose  wrote:
> Thanks for writing this up, Chris! I addressed the idea of making this an 
> arbitrary pattern in the revised proposal 
> ,
>  and the idea of not matching known cases in a "considered alternative" 
> ,
>  but in short:
> 
> - Matching in arbitrary pattern positions is harder to implement and harder 
> to produce good diagnostics for. (Specifically, the former comes from having 
> to actually check the existing cases in the generated code rather than just 
> having an "else" branch.) I'm not inherently opposed to it if we can all 
> agree on what it means, but I don't think I have time to implement it for 
> Swift 5, so I'm not including it in the proposal.

I’m not sure what you’re saying here.  This does slot directly into the 
existing pattern design: it is just a new terminal pattern node.  Are you 
saying the SILGen/IRGen is more difficult and therefore you’re not interested 
in doing it even if it is the better design?  

If that is the case, then the conservatively correct thing to do (in my 
opinion) is to add no feature here: no “unknown case:” and no “case #unknown:’.

Alternatively are you saying that you intend to support only the “case 
#unknown:” form exactly, but not the recursive cases?

> - Matching known cases is a feature, not a limitation, to avoid existing code 
> changing meaning when you recompile. I'll admit that's not the strongest 
> motivation, though, since other things can change the meaning of existing 
> code when you recompile already.

I’m not sure I understand this. 

The whole motivation for this feature is to notify people if they are not 
handling a “newly known” case.  If they don’t care about this, they can just 
use default.

> - FWIW I can't actually think of a use case for using this with `if case` or 
> anything else. I'm not against it, but I don't know why you would ever do it, 
> just like I don't know why you would mix `case #unknown` with `default` when 
> matching against a single value.

Brent gave a simple example down thread.  That said, I’m more concerned about 
keeping pattern matching simple and composable than I am about particular use 
cases (I agree the top level case in a switch on enum is the disproportionately 
important case). 

At some point we will hopefully extend pattern matching to support regexes and 
other things, we want to keep the design consistent.

> That said, it sounds like people are happier with `case #unknown` than 
> `unknown case`, and that leaves things a little more consistent if we ever do 
> expand it to other pattern positions, so I'll change the proposal revision to 
> use that spelling. (And if anyone comes up with a nicer spelling, great!)

Thanks!

-Chris


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

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

[Kelvin Ma via swift-evolution]

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Some thoughts:
>
> - How do I randomly select an enum?
>

carefully, of course


>
> - I like that RandomNumberGenerator doesn’t have an associated type. I
> agree that we should just spit out UInt64s for simplicity.
>
> - I don’t like how it is so closely tied with Range.  I realize that both
> Int and Float work with Ranges, but other random types do not (e.g.
> CGVectors).  You are special casing FixedWidthInteger and
> BinaryFloatingPoint, which are very important… but we lose the ability to
> deal with other randomly generated types.
>

generating “random vectors” is a *big* mood and it’s not as simple as
varying on a range of *R*3. There’s a mild but non-trivial amount of work
needed to get a uniform distribution and avoid degeneracies and division by
zero. and “random” can mean different things, sometimes you want a random
2D disk of vectors that all live in some plane in 3D space because you need
them to be perpendicular to something. And at any rate, CGVector is not a
standard type, while Int and Float are.


>
> - Following on the previous point, I don’t like that the code for dealing
> with Integers/Floats is in Range.  It feels like things aren’t properly
> encapsulated.
>
> - Why bother supporting non-closed Ranges at all?  If you only allow
> closed ranges, then you can’t end up with an empty range. The only
> difference in behavior I can think of is on floating point, but I can’t
> think of a use-case where excluding the supremum is actually useful in any
> real world way.
>

i see this as an inconvenience for the sake of security theater. Usually
when you want a random integer on a continuous range, you’re using them as
indices into something. And indices go from 0 ..< count, not 0 ... (count -
1). if whatever you’re indexing into is empty, it’s empty.


>
> - This may sound strange, but I would *really* like to see Bool handled
> as a default implementation on the generator protocol itself.  On my own
> version of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods
> which I find extremely useful.  CoinFlip just gives you a random bool,
> whereas you can say things like oneIn(100) to get ‘true’ roughly 1 out of
> every 100 times you call it.  These are useful for branching randomly.
> They are most useful on the source/generator itself because it is ergonomic
> when you need to rewind the source.
>
> - IMO distributions should be sources/generators themselves which just
> wrap another source.  We could have a subprotocol of RandomNumberGenerator
> which just semantically guarantees uniform distribution, and then
> distributions that need it could be sure of the input distribution.  Notice
> this doesn’t limit the distribution to only be used for Integers as they
> are in the demo. They can be used anywhere a source can be used.
>
> - Having a subprotocol for generators which can be rewound is extremely
> important for entire classes of real-world problems.  I have spent a lot of
> time using this and it solves a LOT of problems. For example, I have a
> Lorem Ipsum Generator which takes Attributes and a CGSize to fill.  It
> works by branching (using the Bool methods above) and then rewinding bits
> which don’t fit (If you just futz with the last part instead of generating
> appropriate clauses, it won’t look right).  I also have a bunch of
> backtracking algorithms which rely on this rewind ability.  Plus numerous
> visual effects which rely on a repeatable rewindable source.
> *- Tl;dr: It isn’t enough to just have a seed, you need to be able to mark
> a state of a generator and return to that state later.*
>
> My RepeatableRandomSource Protocol has 3 extra methods:
> - It takes a seed
> - It has a mark() method which returns a token
> - It has a returnToMark(_ mark:Mark) method which takes a token and
> restores the appropriate state
>
> - I really appreciate that you made a playground :-)
>
> Thanks,
> Jon
>
>
> On Jan 8, 2018, at 11:02 AM, 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 

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

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez  wrote:
> Hi Chris,
> 
> This is great. Thanks for spending time on this! I am in favor of `case 
> #unknown` to only match unknown cases. 
> 
> 1) Would #uknown be available to RawRepresentable structs?

I haven’t considered this, so I’m not sure how that would work.  I had assumed 
that this would be an enum specific concept.

What do you have in mind?  If your raw representation is itself an enum, then 
of course this would work.

> 2) How is the #uknown pattern accomplished? Are you suggesting to capture all 
> the compile time known cases so you can do a diff during 
> runtime? (Sorry this is not obvious to me)

The internals of the compiler would handle this, it is difficult to explain 
unless you know the bowels of silgen and irgen :-)

-Chris


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

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

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 12:27 PM, Vladimir.S  wrote:
>> 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.
> 
> Are you saying here about situation, when new case is added in non-frozen 
> enum, but we are compiling the old code with absent new case but with 
> "unknown case" in switch? As stated in proposal, in this case we'll have a 
> warning exactly for source compatibility reason: "..unknown case matches any 
> value. ... the compiler will produce a warning if all known elements of the 
> enum have not already been matched. This is a warning rather than an error so 
> that adding new elements to the enum remains a source-compatible change." Do 
> you suggest to change that warning into error?
> 
> Or you are saying about another situation when “unknown case” will match 
> known cases too in the initial proposal ?

In the proposal, ‘unknown case’ is a synonym for default with changes to 
warning generation.  This means that it matches everything, including cases 
known at static compile time.

>> 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.
> 
> Are you suggesting to have this?:
> 
> switch val {
> case .one: ...
> case .two: ...
> case #unknown: ...
> default: ..
> }

Yes.

> So, all new cases, introduced in external module after compilation of that 
> code will fall into "case #unknown: ..." bucket, but all "known"(at the 
> moment of compilation) cases but not .one/.two - into "default:..." ? 
> Personally I like that, so if I need this - I will be able to express this, 
> but that rule seems like complicated to understand.
> But this can be really helpful in situation, when you *at compilation time" 
> thinks that you are not interested in anything but .one/.two cases of that 
> enum, but in case of new values - you want to show(for example) a warning for 
> app user.

Exactly.  It is a narrow case, but it is important to me that we provide 
primitives that compose properly.

> 
> Do I understand correctly, that you suggest the same behavior as in 
> original(updated) proposal:
> * if we have a switch on non-frozen enum value, and enumerated some cases, 
> and have "case #unknown" - we'll have a warning(error?) if (at the moment of 
> compilation) not all known enums are processed in "switch” ?

Yes.

> Just to be sure.
> 
> Btw, should this be valid? :
> switch val {
>  case #unknown:... // I'm only interested if new values were added to that 
> external enum
>  default: ... // as I understand, "default" will be required here
> }

Yes, this would be very weird to write, but would be valid: the default matches 
all known cases at compile time.  I’d suggest that you write that as a “if case 
#unknown” with an else though.

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution 
 wrote:
> Good afternoon,

Hi Connor,

Huge +1 for this proposal, I’m thrilled you’re cleaning this up.  Couple of 
detail questions:

>  
> 
> Detailed design
> 
> To provide a more flexible API, we propose deprecating and ultimately 
> removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable 
> protocol in favor of a simpler design. Instead, we propose introducing a 
> protocol which just provides the ability to return an Any (or nil) that 
> serves as a stand-in for the instance being logged:
> 

What is the use-case for a type conforming to this protocol but returning nil?  
If there is a use case for that, why not have such an implementation return 
“self” instead?

In short, can we change playgroundRepresentation to return Any instead of Any?. 
 Among other things, doing so could ease the case of playground formatting 
Optional itself, which should presumably get a conditional conformance to this. 
 :-)


> /// Implementors of `CustomPlaygroundRepresentable` may return a value of one 
> of
> /// the above types to also receive a specialized log representation.
> /// Implementors may also return any other type, and playground logging will
> /// generated structured logging for the returned value.
> public protocol CustomPlaygroundRepresentable {
On the naming bikeshed, the closest analog to this feature is 
CustomStringConvertible, which is used when a type wants to customize the 
default conversion to string.  As such, have you considered 
CustomPlaygroundConvertible for consistency with it?

The only prior art for the word “Representable” in the standard library is 
RawRepresentable, which is quite a different concept.

>   /// Returns the custom playground representation for this instance, or nil 
> if
>   /// the default representation should be used.
>   ///
>   /// If this type has value semantics, the instance returned should be
>   /// unaffected by subsequent mutations if possible.
>   var playgroundRepresentation: Any? { get }
Again to align with CustomStringConvertible which has a ‘description’ member, 
it might make sense to name this member “playgroundDescription”.

Thank you again for pushing this forward, this will be much cleaner!

-Chris


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

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

[Antoine Cœur via swift-evolution]

I'm not in favor to distinguish #unknown and #known, as it may lead to
surprises, like something that previously was unknown becomes known on a
newer iOS version for instance. And version-dependant code is clearer if
solely handled by the `@available()` syntax.

I like the new pattern matching syntax proposal, but I feel it would also
work by naming it `default` instead of `unknown`:

case (_, default): …  matches any int and any unknown enum case ...


Le mer. 10 janv. 2018 à 08:46, Jordan Rose via swift-evolution <
swift-evolution@swift.org> a écrit :

>
>
> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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.
>

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> - FWIW I can't actually think of a use case for using this with `if case` or 
> anything else. I'm not against it, but I don't know why you would ever do it, 
> just like I don't know why you would mix `case #unknown` with `default` when 
> matching against a single value.

if case #unknown = someEnum {
throw MyError.unknownValue
}
…

> That said, it sounds like people are happier with `case #unknown` than 
> `unknown case`, and that leaves things a little more consistent if we ever do 
> expand it to other pattern positions, so I'll change the proposal revision to 
> use that spelling. (And if anyone comes up with a nicer spelling, great!)

I don't love the spelling of `#unknown`—particularly since some enums in the 
Apple frameworks actually *have* an ordinary case called "unknown"—but I think 
it's a nice, pragmatic solution which slots into pattern matching very nicely.

(And if we ever *do* decide to support @testable enum parameters, we'll already 
have the syntax to specify unknown values.)

-- 
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 9, 2018, at 9:04 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> The problem is that this isn't currently expressible in the type system. If 
> we can, I would actually support including some kind of unprincipled private 
> hack so we could say `where Element: _AnyTupleOfTwo`.


Sorry, I meant to provide an alternative but forgot.

If we can't do this, I think we should call it something like `PairArray` or 
`KeyValueArray` and augment its API to bring it closer to parity with `Array`. 
This type really does have the same semantics as `Array`—integer-indexed, 
order-preserving, random-access, etc.—and I think we should leverage that fact 
to make its behavior clear.

`PairArray` sort of vaguely suggests that we should have a `public typealias 
Pair = (key: K, value: V)` in the standard library. I think that's 
actually a good idea, because we can use it to make sure that we use tuple 
element labels consistently across various APIs.

-- 
Brent Royal-Gordon
Architechies

___
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

[Brent Royal-Gordon via swift-evolution]

> On Jan 8, 2018, at 11:02 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> 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.


For what it's worth, I *might* introduce a follow-up proposal with conformances 
for Bool and Optional. Their straightforwardness and utility make them very 
tempting.

(The only questions are whether `false` and `nil` should be first or last. But 
if the default isn't right for your use case, you can always make your own 
static property instead of using the standard library's.)

-- 
Brent Royal-Gordon
Architechies

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

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

[Charles Constant via swift-evolution]

Oops. Kindly disregard my previous emails. Ben was kind enough to point out
to me that I was confusing dictionary literals with DictionaryLiteral

On Tue, Jan 9, 2018 at 8:56 PM, Ben Cohen <> wrote:

> Hi Charles,
>
> The naming issue strikes again :)
>
> Your code is making use of dictionary literals, not DictionaryLiteral. We
> are talking about the (clearly confusingly named!) DictionaryLiteral type,
> which is a type you can create from a dictionary literal. (See docs here:
> https://developer.apple.com/documentation/swift/dictionaryliteral)
>
> There’s no suggestion of getting rid of the ExpressibleByDictionaryLiteral
> capability.
>
> “Ceci n’est pas une literal”
>  - Magritte
>
> On Jan 9, 2018, at 8:26 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Nevin (et al)
>
> Here's the relevant section of my code. It's from a protocol I use called
> "ParameterSet" to extend OptionSets to contain small numbers (like an Enum
> with an associated type, but all the data is stored in the UInt). Wouldn't
> be my first choice to share, as it breaks KISS. Anyhow, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
>> charlesism@gmail.com> wrote:
>>
>>> I used a DictionaryLiteral only yesterday, and it turned what would have
>>> a typically unreadable array of Structs into something much more elegant.
>>> I'm pretty sure the only reason Literals (of all varieties) aren't used
>>> more often is because Swift programmers don't realize they are available
>>> and easy to implement.
>>>
>>
>> Could you provide an example of how you used DictionaryLiteral?
>>
>> Nevin
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
On Tue, Jan 9, 2018 at 8:26 PM, Charles Constant via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Nevin (et al)
>
> Here's the relevant section of my code. It's from a protocol I use called
> "ParameterSet" to extend OptionSets to contain small numbers (like an Enum
> with an associated type, but all the data is stored in the UInt). Wouldn't
> be my first choice to share, as it breaks KISS. Anyhow, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
>> charlesism@gmail.com> wrote:
>>
>>> I used a DictionaryLiteral only yesterday, and it turned what would have
>>> a typically unreadable array of Structs into something much more elegant.
>>> I'm pretty sure the only reason Literals (of all varieties) aren't used
>>> more often is because Swift programmers don't realize they are available
>>> and easy to implement.
>>>
>>
>> Could you provide an example of how you used DictionaryLiteral?
>>
>> Nevin
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 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.


I think the best solution by far would be to provide an `extension Array: 
ExpressibleByDictionaryLiteral where Element == (Key, Value)` conformance. 
Besides the name, `DictionaryLiteral` basically has the same semantics as 
`Array`, but an impoverished subset of its functionality; using `Array` would 
reduce the standard library's surface area *and* improve the usability of code 
which currently uses `DictionaryLiteral`.

The problem is that this isn't currently expressible in the type system. If we 
can, I would actually support including some kind of unprincipled private hack 
so we could say `where Element: _AnyTupleOfTwo`. It seems like enough of a win, 
in both surface area and functionality, to justify a little compiler weirdness. 
(And we don't need to test for `_AnyTupleOfTwo` conformance at runtime, so I 
don't think it's a problem if `is` and `as?` don't work.)

-- 
Brent Royal-Gordon
Architechies

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

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

[Charles Constant via swift-evolution]

Hi Nevin (et al)

Here's the relevant section of my code. It's from a protocol I use called
"ParameterSet" to extend OptionSets to contain small numbers (like an Enum
with an associated type, but all the data is stored in the UInt). Wouldn't
be my first choice to share, as it breaks KISS. Anyhow, the
"ExpressibleByDictionaryLiteral" lets me specify a "params" template
tersely. I only found out how to use the -Literal initializers last year. I
love them.

struct DrumNote: ParameterSet {
let rawValue: UInt

static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
"reverse" ]

static let
velocity = param(0),
flam = param(1),
roll = param(2),
reverse = param(3),

// ...

}

enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral {
public init( dictionaryLiteral elements: (String,Any)... ) {
if let pair = elements.first as? (String,ClosedRange) {
self = .doub(pair.0,pair.1) }
else if let pair = elements.first as?
(String,CountableClosedRange) { self = .int(pair.0,
pair.1.lowerBound ... pair.1.upperBound ) }
else { fatalError("Can only init from Double...Double or Int...Int") }
}

// ...
}


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

> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
> charlesism@gmail.com> wrote:
>
>> I used a DictionaryLiteral only yesterday, and it turned what would have
>> a typically unreadable array of Structs into something much more elegant.
>> I'm pretty sure the only reason Literals (of all varieties) aren't used
>> more often is because Swift programmers don't realize they are available
>> and easy to implement.
>>
>
> Could you provide an example of how you used DictionaryLiteral?
>
> Nevin
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Incremental ABI stability

[Jon Hull via swift-evolution]

+1000

I would like to be even more conservative, only locking down the things we know 
we have received actual human attention of some sort. The all-or-nothing 
approach is actively harmful in my mind.

Thanks,
Jon

Sent from my iPhone

> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> I’m just spitballing here, and I’m not an expert on matters of ABI, however 
> the thought occurs to me that the current all-or-nothing approach might lead 
> to suboptimal results.
> 
> In particular, some recent discussions on this list have mentioned that 
> certain parts of the standard library, such as Mirror, really ought to be 
> redesigned. But their current shape is on track to be baked into the 
> permanent ABI, even though we know right now that we can do better.
> 
> Has any consideration been given to the possibility of carving out specific 
> exemptions to ABI stability for Swift 5, and saying something like, “The 
> entire ABI will be stabilized, except for Mirror (and possibly a small number 
> of other things)”?
> 
> That way we can nail down almost all of the ABI, while still being able to 
> fix the parts that we can already see need fixing. Perhaps I am being naive 
> here, and I’m sure there are major aspects I am unaware of, but from my 
> layperson’s perspective it seems rather silly to tie ourselves to a legacy 
> implementation that we want to redesign.
> 
> Nevin
> ___
> 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

[Nevin Brackett-Rozinsky via swift-evolution]

On Tue, Jan 9, 2018 at 9:27 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this type might become more useful if we find a good name for it
> and better document it. For example, it is a natural fit for parameter list
> of Chris’ callable type proposal.
>
> Since this type accepts duplicate “keys” and does not provide key-based
> lookup, the first thing that deserves a rename is “Key” generic parameter.
> I recommend naming it “Label”.
>
> This type represents how a dictionary literal *looks*, not what it *means*.
> When we consider the look of it, a dictionary literal is an array literal
> where each element is labeled.
>
> I can’t think of a really good name, but we may be able to find a more
> accurate and less confusing name.
>
> Some of the more accurate names are:
>
> LabeledElementCollection
> LabeledValueCollection
> LabeledValueList
> LabeledList
>
> By the way, why this type does not conform to any of the collection
> protocols while duplicating a lot of collection APIs?
>


+1 to “LabeledList”

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

[swift-evolution] Incremental ABI stability

[Nevin Brackett-Rozinsky via swift-evolution]

I’m just spitballing here, and I’m not an expert on matters of ABI, however
the thought occurs to me that the current all-or-nothing approach might
lead to suboptimal results.

In particular, some recent discussions on this list have mentioned that
certain parts of the standard library, such as Mirror, really ought to be
redesigned. But their current shape is on track to be baked into the
permanent ABI, even though we know right now that we can do better.

Has any consideration been given to the possibility of carving out specific
exemptions to ABI stability for Swift 5, and saying something like, “The
entire ABI will be stabilized, except for Mirror (and possibly a small
number of other things)”?

That way we can nail down almost all of the ABI, while still being able to
fix the parts that we can already see need fixing. Perhaps I am being naive
here, and I’m sure there are major aspects I am unaware of, but from my
layperson’s perspective it seems rather silly to tie ourselves to a legacy
implementation that we want to redesign.

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

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

[Hooman Mehr via swift-evolution]

I think this type might become more useful if we find a good name for it and 
better document it. For example, it is a natural fit for parameter list of 
Chris’ callable type proposal.

Since this type accepts duplicate “keys” and does not provide key-based lookup, 
the first thing that deserves a rename is “Key” generic parameter. I recommend 
naming it “Label”.  

This type represents how a dictionary literal looks, not what it means. When we 
consider the look of it, a dictionary literal is an array literal where each 
element is labeled. 

I can’t think of a really good name, but we may be able to find a more accurate 
and less confusing name.

Some of the more accurate names are:

LabeledElementCollection
LabeledValueCollection
LabeledValueList
LabeledList

By the way, why this type does not conform to any of the collection protocols 
while duplicating a lot of collection APIs?

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

___
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 Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
charlesism@gmail.com> wrote:

> I used a DictionaryLiteral only yesterday, and it turned what would have a
> typically unreadable array of Structs into something much more elegant. I'm
> pretty sure the only reason Literals (of all varieties) aren't used more
> often is because Swift programmers don't realize they are available and
> easy to implement.
>

Could you provide an example of how you used DictionaryLiteral?

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Connor Wakamo via swift-evolution]

> On Jan 9, 2018, at 4:21 PM, Ben Rimmington  wrote:
> 
> Something like this was attempted (and reverted) for Swift 3:
> 
> 
> 
> 
> 
> 
> 
> Is it now possible to `import PlaygroundSupport` outside of a playground?

No, it is not. This is a known limitation of the proposal that is acknowledged 
in the full text of the proposal.

For the corelibs case (and for libraries provided by the OS), it’s expected 
that the PlaygroundLogger library be updated to support generating rich log 
data for new types.

For third-party modules there’s not a great solution, though since playgrounds 
have fairly limited access to third-party modules and because usage of 
CustomPlaygroundQuickLookable outside of playgrounds is low (as determined by 
searching GitHub and the source compatibility suite), the proposal asserts that 
this is a reasonable trade-off for removing something this domain-specific from 
the standard library.

Since the new protocol doesn’t itself use any custom types, a workaround for 
this limitation is possible:

// MyFramework.swift
public struct MyStruct {
var playgroundRepresentation: Any? { … }
}

// PlaygroundAuxiliarySource.swift
import MyFramework
import PlaygroundSupport

extension MyStruct: CustomPlaygroundRepresentable {}

The proposal intentionally chose to place this in PlaygroundSupport instead of 
the standard library because it should be possible in a future Swift release to 
move this protocol from PlaygroundSupport to the standard library (because 
PlaygroundSupport doesn’t have any ABI concerns at this time), whereas it 
wouldn’t be possible to go in the reverse direction. (And if we determine that 
this protocol should live in the standard library during the course of the 
review process, I’d still want to proceed otherwise as planned — add the new 
protocol, deprecate-then-remove the old protocol/enum, and provide a shim 
library for playgrounds only.)

Connor

> 
> -- Ben
> 
>> On 9 Jan 2018, at 23:19, Connor Wakamo wrote:
>> 
>> Good afternoon,
>> 
>> In preparation for ABI stability, I’ve reviewed the API exposed by the 
>> standard library for providing customized “quick looks” in playgrounds. This 
>> is exposed as the PlaygroundQuickLook enum and the 
>> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a 
>> handful of issues:
>> 
>>  - It hard-codes the list of supported types in the standard library, 
>> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
>> standard library changes (including swift-evolution review)
>>  - The cases of the enum are poorly typed: there are cases like `.view` 
>> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
>> since they’re in the standard library, they have to be typed as taking `Any` 
>> instead
>>  - The names of some of these enum cases do not seem to match Swift 
>> naming conventions)
>> 
>> To that end, I am proposing the following:
>> 
>>  - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
>> Swift 4.1 (including in the Swift 3 compatibility mode)
>>  - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
>> 5 to avoid including them in the stable ABI (this affects the compatibility 
>> modes, too)
>>  - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
>> PlaygroundSupport library in Swift 4.1:
>> 
>>  protocol CustomPlaygroundRepresentable {
>>  /// Returns an alternate object or value which should 
>> stand in for the receiver in playground logging, or nil if the receiver’s 
>> default representation is preferred.
>>  var playgroundRepresentation: Any? { get }
>>  }
>> 
>>  - Update the PlaygroundLogger library in Swift 4.1 to support both 
>> CustomPlaygroundRepresentable and 
>> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>>  - Provide a compatibility shim library which preserves 
>> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
>> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
>> auxiliary source files stored inside a playground)
>> 
>> I’ve put a full proposal below. Please let me know what you think of this 
>> proposal; I’d like to get some feedback before taking this through the 
>> review process, but I’ll need to get that quickly so I can get it under 
>> review soon as this is targeted at Swift 4.1.
>> 
>> Thanks,
>> Connor

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Jordan Rose via swift-evolution]

I'm not sure how this solves the problem. We need to know whether an enum may 
grow new cases or not, a concept that doesn't exist in Swift today. This is 
most interesting for enums in "libraries with binary compatibility concerns", 
but is also interesting for libraries that don't have such concerns, like 
source packages. Source packages don't use availability annotations.

We definitely need to be able to mark when enum cases were introduced, but the 
language already supports that, at least for libraries that are shipped with an 
Apple OS.

As for the name, I agree that 'exhaustive' isn't great. The best suggestion we 
got from the initial review was 'frozen', and that's what I'm putting in the 
next revision of the proposal.

Jordan

P.S. I'm not sure where you got "versioned" from. The attribute currently 
spelled '_versioned' in the Swift compiler is equivalent to what SE-0193 

 calls 'abiPublic', at least in this revision. (I'm sorry to say I haven't 
caught up on all the discussion there, so I don't know if that's going to be 
spelled some other way.)



> On Jan 9, 2018, at 08:52, Jon Gilbert  wrote:
> 
> Having reviewed much of the commentary on this proposal, I keep coming back 
> to the same thought: why not use @versioned and @available keywords for this 
> instead of some concept related to “exhaustive”?
> 
> The issue here is not whether a given enum is “exhaustive” over the 
> enumerated problem space; it’s whether the developer wants to alter the enum 
> in the future without breaking ABI compatibility.
> 
> If you call it “exhaustive” then it’s misleading, because all enums at a 
> given moment in time can be switched over exhaustively. This will just 
> confuse folks.
> 
> Since versioning is really the main goal, why not use the same annotations 
> for versioning enums as are used for versioning everything else?
> 
> @versioned
> enum MyError: Error {
> @available(OSX, deprecated:10.11, message: "this error case is going away in 
> 10.12")
> case BadThingHappened
> 
> @available(forever)
> case ReallyBadThingHappened
> }
> 
> etc.
> 
> That way you could have some cases get removed in the future as well as 
> added, and you won’t confuse people by talking about “complete” or 
> “exhaustive”, which are terms that are too closely coupled with the meaning 
> and application of a given enum to which they refer. 
> 
> It would be best to use terms that just say what they mean. We are talking 
> about versioning APIs to keep ABI stability? Use @versioned and @available 
> like everywhere else. 
> 
> Or is there a compelling reason this cannot be done? I read much of the 
> arguments here but didn’t see any mention of @versioned... maybe it’s iOS 
> Mail app thinking I was looking for an email address that contains 
> @versioned? ;D
> 
> Jonathan

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

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

[charles--- via swift-evolution]

I used a DictionaryLiteral only yesterday, and it turned what would have a 
typically unreadable array of Structs into something much more elegant. I'm 
pretty sure the only reason Literals (of all varieties) aren't used more often 
is because Swift programmers don't realize they are available and easy to 
implement. 

Sent from my telephone

> On Jan 8, 2018, at 9:40 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
>> On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution 
>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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 

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Ben Rimmington via swift-evolution]

Something like this was attempted (and reverted) for Swift 3:







Is it now possible to `import PlaygroundSupport` outside of a playground?

-- Ben

> On 9 Jan 2018, at 23:19, Connor Wakamo wrote:
> 
> Good afternoon,
> 
> In preparation for ABI stability, I’ve reviewed the API exposed by the 
> standard library for providing customized “quick looks” in playgrounds. This 
> is exposed as the PlaygroundQuickLook enum and the 
> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a handful 
> of issues:
> 
>   - It hard-codes the list of supported types in the standard library, 
> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
> standard library changes (including swift-evolution review)
>   - The cases of the enum are poorly typed: there are cases like `.view` 
> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
> since they’re in the standard library, they have to be typed as taking `Any` 
> instead
>   - The names of some of these enum cases do not seem to match Swift 
> naming conventions)
> 
> To that end, I am proposing the following:
> 
>   - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
> Swift 4.1 (including in the Swift 3 compatibility mode)
>   - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
> 5 to avoid including them in the stable ABI (this affects the compatibility 
> modes, too)
>   - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
> PlaygroundSupport library in Swift 4.1:
> 
>   protocol CustomPlaygroundRepresentable {
>   /// Returns an alternate object or value which should 
> stand in for the receiver in playground logging, or nil if the receiver’s 
> default representation is preferred.
>   var playgroundRepresentation: Any? { get }
>   }
> 
>   - Update the PlaygroundLogger library in Swift 4.1 to support both 
> CustomPlaygroundRepresentable and 
> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>   - Provide a compatibility shim library which preserves 
> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
> auxiliary source files stored inside a playground)
> 
> I’ve put a full proposal below. Please let me know what you think of this 
> proposal; I’d like to get some feedback before taking this through the review 
> process, but I’ll need to get that quickly so I can get it under review soon 
> as this is targeted at Swift 4.1.
> 
> Thanks,
> Connor
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Connor Wakamo via swift-evolution]

Yes, it will — if a type does not conform to `CustomPlaygroundRepresentable`, 
PlaygroundLogger will continue to log it structurally.

Connor

> On Jan 9, 2018, at 3:56 PM, Saagar Jha  wrote:
> 
> I’ve just glanced through this, so I apologize if this was already addressed, 
> but will the default behavior (i.e. that of something that doesn’t conform to 
> CustomPlaygroundRepresentable) remain the same?
> 
> Saagar Jha
> 
>> On Jan 9, 2018, at 15:19, Connor Wakamo via swift-evolution 
>> > wrote:
>> 
>> Good afternoon,
>> 
>> In preparation for ABI stability, I’ve reviewed the API exposed by the 
>> standard library for providing customized “quick looks” in playgrounds. This 
>> is exposed as the PlaygroundQuickLook enum and the 
>> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a 
>> handful of issues:
>> 
>>  - It hard-codes the list of supported types in the standard library, 
>> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
>> standard library changes (including swift-evolution review)
>>  - The cases of the enum are poorly typed: there are cases like `.view` 
>> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
>> since they’re in the standard library, they have to be typed as taking `Any` 
>> instead
>>  - The names of some of these enum cases do not seem to match Swift 
>> naming conventions)
>> 
>> To that end, I am proposing the following:
>> 
>>  - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
>> Swift 4.1 (including in the Swift 3 compatibility mode)
>>  - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
>> 5 to avoid including them in the stable ABI (this affects the compatibility 
>> modes, too)
>>  - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
>> PlaygroundSupport library in Swift 4.1:
>> 
>>  protocol CustomPlaygroundRepresentable {
>>  /// Returns an alternate object or value which should 
>> stand in for the receiver in playground logging, or nil if the receiver’s 
>> default representation is preferred.
>>  var playgroundRepresentation: Any? { get }
>>  }
>> 
>>  - Update the PlaygroundLogger library in Swift 4.1 to support both 
>> CustomPlaygroundRepresentable and 
>> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>>  - Provide a compatibility shim library which preserves 
>> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
>> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
>> auxiliary source files stored inside a playground)
>> 
>> I’ve put a full proposal below. Please let me know what you think of this 
>> proposal; I’d like to get some feedback before taking this through the 
>> review process, but I’ll need to get that quickly so I can get it under 
>> review soon as this is targeted at Swift 4.1.
>> 
>> Thanks,
>> Connor
>> 
>> —
>> 
>> Playground QuickLook API Revamp
>> 
>> Proposal: SE- 
>> 
>> Authors: Connor Wakamo 
>> Review Manager: TBD
>> Status: Awaiting implementation
>>  
>> Introduction
>> 
>> The standard library currently includes API which allows a type to customize 
>> its representation in Xcode playgrounds and Swift Playgrounds. This API 
>> takes the form of the PlaygroundQuickLook enum which enumerates types which 
>> are supported for quick looks, and the CustomPlaygroundQuickLookable 
>> protocol which allows a type to return a custom PlaygroundQuickLook value 
>> for an instance.
>> 
>> This is brittle, and to avoid dependency inversions, many of the cases are 
>> typed as taking Any instead of a more appropriate type. This proposal 
>> suggests that we deprecate PlaygroundQuickLook and 
>> CustomPlaygroundQuickLookable in Swift 4.1 so they can be removed entirely 
>> in Swift 5, preventing them from being included in the standard library's 
>> stable ABI. To maintain compatibility with older playgrounds, the deprecated 
>> symbols will be present in a temporary compatibility shim library which will 
>> be automatically imported in playground contexts. (This will represent an 
>> intentional source break for projects, packages, and other non-playground 
>> Swift code which use PlaygroundQuickLook or CustomPlaygroundQuickLookable 
>> when they switch to the Swift 5.0 compiler, even in the compatibility modes.)
>> 
>> Since it is still useful to allow types to provide alternate representations 
>> for playgrounds, we propose to add a new protocol to the PlaygroundSupport 
>> framework which allows types to do just that. 

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Ben Cohen via swift-evolution]

Big +1 to this. Getting these types out of the standard library and into a more 
suitable domain-specific framework, prior to declaring ABI Stability, will give 
us flexibility to evolve them appropriately over time.

> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution 
>  wrote:
> 
> Good afternoon,
> 
> In preparation for ABI stability, I’ve reviewed the API exposed by the 
> standard library for providing customized “quick looks” in playgrounds. This 
> is exposed as the PlaygroundQuickLook enum and the 
> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a handful 
> of issues:
> 
>   - It hard-codes the list of supported types in the standard library, 
> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
> standard library changes (including swift-evolution review)
>   - The cases of the enum are poorly typed: there are cases like `.view` 
> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
> since they’re in the standard library, they have to be typed as taking `Any` 
> instead
>   - The names of some of these enum cases do not seem to match Swift 
> naming conventions)
> 
> To that end, I am proposing the following:
> 
>   - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
> Swift 4.1 (including in the Swift 3 compatibility mode)
>   - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
> 5 to avoid including them in the stable ABI (this affects the compatibility 
> modes, too)
>   - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
> PlaygroundSupport library in Swift 4.1:
> 
>   protocol CustomPlaygroundRepresentable {
>   /// Returns an alternate object or value which should 
> stand in for the receiver in playground logging, or nil if the receiver’s 
> default representation is preferred.
>   var playgroundRepresentation: Any? { get }
>   }
> 
>   - Update the PlaygroundLogger library in Swift 4.1 to support both 
> CustomPlaygroundRepresentable and 
> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>   - Provide a compatibility shim library which preserves 
> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
> auxiliary source files stored inside a playground)
> 
> I’ve put a full proposal below. Please let me know what you think of this 
> proposal; I’d like to get some feedback before taking this through the review 
> process, but I’ll need to get that quickly so I can get it under review soon 
> as this is targeted at Swift 4.1.
> 
> Thanks,
> Connor
> 
> —
> 
> Playground QuickLook API Revamp
> 
> Proposal: SE- 
> 
> Authors: Connor Wakamo 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> The standard library currently includes API which allows a type to customize 
> its representation in Xcode playgrounds and Swift Playgrounds. This API takes 
> the form of the PlaygroundQuickLook enum which enumerates types which are 
> supported for quick looks, and the CustomPlaygroundQuickLookable protocol 
> which allows a type to return a custom PlaygroundQuickLook value for an 
> instance.
> 
> This is brittle, and to avoid dependency inversions, many of the cases are 
> typed as taking Any instead of a more appropriate type. This proposal 
> suggests that we deprecate PlaygroundQuickLook and 
> CustomPlaygroundQuickLookable in Swift 4.1 so they can be removed entirely in 
> Swift 5, preventing them from being included in the standard library's stable 
> ABI. To maintain compatibility with older playgrounds, the deprecated symbols 
> will be present in a temporary compatibility shim library which will be 
> automatically imported in playground contexts. (This will represent an 
> intentional source break for projects, packages, and other non-playground 
> Swift code which use PlaygroundQuickLook or CustomPlaygroundQuickLookable 
> when they switch to the Swift 5.0 compiler, even in the compatibility modes.)
> 
> Since it is still useful to allow types to provide alternate representations 
> for playgrounds, we propose to add a new protocol to the PlaygroundSupport 
> framework which allows types to do just that. (PlaygroundSupport is a 
> framework delivered by the swift-xcode-playground-support project 
>  which provides API 
> specific to working in the playgrounds environment). The new 
> CustomPlaygroundRepresentable protocol would allow instances to return an 
> alternate object or value (as an 

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

[Ben Cohen via swift-evolution]

> On Jan 9, 2018, at 11:48 AM, Chris Lattner  wrote:
> 
>> On Jan 9, 2018, at 10:23 AM, Ben Cohen  wrote:
 
 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?  
>> 
>> Given it’s going to be in the ABI regardless, and has at least some marginal 
>> utility, if we can find a more sensible name for it is there any strong 
>> motivation to deprecate it?
> 
> +1 for renaming it to something that isn’t super confusing, but +100 for 
> removing it outright.
> 
> Rationale: if we didn’t have this functionality in the stdlib today, we would 
> not consider adding it.  It doesn’t meet the bar we’ve set for what is in the 
> standard library.  It only exists there by historical accident.  The Mirror 
> API was not carefully considered.
> 

Personally, I feel like this argument for removal as past its use-by date. It 
was a good reason for Swift 3, tenuous for 4 and should be ruled out for 5, 
since the source stability bar has been raised since. Like I said, IMO the 
criteria should now be “active harm”. I also don’t think searches of GitHub etc 
are sufficient justification, except when combined with the active-harm 
argument. I also don’t think the origin story of the type – whether accidental 
or intentional – is relevant to the decision of what to do with it now. It 
exists and people can legitimately use it for their own purposes independent of 
mirrors.

>>> Finally, is anyone actually using this type?
>>> 
>> 
>> IMO that isn’t a question we should be asking any more except in cases where 
>> an existing implementation is causing active harm. Which, confusing name 
>> aside, this type isn’t (aside from API sprawl I guess).
> 
> It directly impacts code size for applications of swift that use the standard 
> library as a standard library, e.g. a raspberry pi dev situation.  It is also 
> bloat, and also takes us down a slippery slope by allowing people to say “if 
> that weird thing is in, why can’t I add my own narrow enhancement?”
> 

The bar for removal and the bar for additions are different. I don’t buy the 
slippery slope argument, and surely neither would anyone else if it were used 
as a justification for new frivolous additions, so this seems like a non-issue 
to me.

> 
> More to the point though, this seems like an implementation detail of 
> Mirrors.  What is the plan for Mirrors + ABI stability?
> 

Absent a proposal to change them to something better (and I’m not aware of one 
pending), the plan is they are what they are, at least the public API of 
Swift.Mirror. I would guess this whole area is a candidate to be overhauled 
significantly at some point in the post-Swift 5 future with some more 
fully-fledged reflection system, but there is little chance of this happening 
before ABI stability, and interim tinkering doesn’t seem worthwhile to me.

> -Chris


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

[swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Connor Wakamo via swift-evolution]

Good afternoon,

In preparation for ABI stability, I’ve reviewed the API exposed by the standard 
library for providing customized “quick looks” in playgrounds. This is exposed 
as the PlaygroundQuickLook enum and the CustomPlaygroundQuickLookable protocol. 
The PlaygroundQuickLook has a handful of issues:

- It hard-codes the list of supported types in the standard library, 
meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
standard library changes (including swift-evolution review)
- The cases of the enum are poorly typed: there are cases like `.view` 
and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
since they’re in the standard library, they have to be typed as taking `Any` 
instead
- The names of some of these enum cases do not seem to match Swift 
naming conventions)

To that end, I am proposing the following:

- Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
Swift 4.1 (including in the Swift 3 compatibility mode)
- Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
5 to avoid including them in the stable ABI (this affects the compatibility 
modes, too)
- Introduce a new protocol, CustomPlaygroundRepresentable, in the 
PlaygroundSupport library in Swift 4.1:

protocol CustomPlaygroundRepresentable {
/// Returns an alternate object or value which should 
stand in for the receiver in playground logging, or nil if the receiver’s 
default representation is preferred.
var playgroundRepresentation: Any? { get }
}

- Update the PlaygroundLogger library in Swift 4.1 to support both 
CustomPlaygroundRepresentable and 
PlaygroundQuickLook/CustomPlaygroundQuickLookable
- Provide a compatibility shim library which preserves 
PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
auxiliary source files stored inside a playground)

I’ve put a full proposal below. Please let me know what you think of this 
proposal; I’d like to get some feedback before taking this through the review 
process, but I’ll need to get that quickly so I can get it under review soon as 
this is targeted at Swift 4.1.

Thanks,
Connor

—

Playground QuickLook API Revamp

Proposal: SE- 

Authors: Connor Wakamo 
Review Manager: TBD
Status: Awaiting implementation
 
Introduction

The standard library currently includes API which allows a type to customize 
its representation in Xcode playgrounds and Swift Playgrounds. This API takes 
the form of the PlaygroundQuickLook enum which enumerates types which are 
supported for quick looks, and the CustomPlaygroundQuickLookable protocol which 
allows a type to return a custom PlaygroundQuickLook value for an instance.

This is brittle, and to avoid dependency inversions, many of the cases are 
typed as taking Any instead of a more appropriate type. This proposal suggests 
that we deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
Swift 4.1 so they can be removed entirely in Swift 5, preventing them from 
being included in the standard library's stable ABI. To maintain compatibility 
with older playgrounds, the deprecated symbols will be present in a temporary 
compatibility shim library which will be automatically imported in playground 
contexts. (This will represent an intentional source break for projects, 
packages, and other non-playground Swift code which use PlaygroundQuickLook or 
CustomPlaygroundQuickLookable when they switch to the Swift 5.0 compiler, even 
in the compatibility modes.)

Since it is still useful to allow types to provide alternate representations 
for playgrounds, we propose to add a new protocol to the PlaygroundSupport 
framework which allows types to do just that. (PlaygroundSupport is a framework 
delivered by the swift-xcode-playground-support project 
 which provides API 
specific to working in the playgrounds environment). The new 
CustomPlaygroundRepresentable protocol would allow instances to return an 
alternate object or value (as an Any) which would serve as their 
representation. The PlaygroundLogger framework, also part of 
swift-xcode-playground-support, will be updated to understand this protocol.

Swift-evolution thread: Discussion thread topic for that proposal 

 
Motivation

The PlaygroundQuickLook enum which currently exists in the standard library is 

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

[Jose Cheyo Jimenez via swift-evolution]

Hi Chris,

This is great. Thanks for spending time on this! I am in favor of `case
#unknown` to only match unknown cases.

1) Would #uknown be available to RawRepresentable structs?

2) How is the #uknown pattern accomplished? Are you suggesting to capture
all the compile time known cases so you can do a diff during
runtime? (Sorry this is not obvious to me)

Previously I suggested having something like `case #known` that would only
match known cases by capturing known cases at compile time ( maybe using a
compile-time variation of
https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md).
This would give us the equivalent of `case _` == `case #known` + `case
#unknown`.  The only issue I found with `case #known`  is that it would be
the same as `case _` when working with an exhaustive enum.

switch myEnum{
case .X :   //
case .Y :   //
case #unknown : // Matches all runtime unknown cases
case #known : //  Matches all compile known cases
}

On Mon, Jan 8, 2018 at 10:54 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, 

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

[Vladimir.S via swift-evolution]

On 09.01.2018 21:43, Kevin Nattinger via swift-evolution wrote:

Proposal link:


https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md


  


  * What is your evaluation of the proposal?

+1 on the general problem, but I have a few comments on the design specifics

- I'd very much prefer automatic synthesis with enums,
- I strongly feel the compiler should auto-generate the implementation in an 
extension for enums.
- Should we add `ValueCollection.Index == Int` to the associatedtype so it can 
always be indexed as in a table?
   - At the least, we should ensure the synthesized implementation is 
int-indexed for tables.
- I feel we should allow auto-generation of imported c enums in an extension, as just an array of the known cases rather 
than the magical metadata iterator if necessary.




FWIW +1 for all Kevin said


  * Is the problem being addressed significant enough to warrant a change to 
Swift?

Definitely. It's been a gaping hole in the language since the beginning.


  * 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 prefer Java's automatic allValues(), but this is better than nothing.


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

Followed at least the start of several threads and read the proposal.


___
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

[Jonathan Hull via swift-evolution]

> On Jan 9, 2018, at 8:28 AM, Nate Cook  wrote:
> 
>> On Jan 9, 2018, at 4:12 AM, Jonathan Hull > > wrote:
>> 
>> Some thoughts:
>> 
>> - How do I randomly select an enum?
> 
> Vote for SE-0194! :)
> 
>> - I like that RandomNumberGenerator doesn’t have an associated type. I agree 
>> that we should just spit out UInt64s for simplicity.
> 
> It simplifies things a lot, at some performance cost. For example, the LCRNG 
> type really produces UInt32s, so I have to use two of its outputs to generate 
> one value, even if I don’t need that many bits.

I agree with you, but just to play devil’s advocate, why not have two outputs: 
one for UInt32 and another for UInt64?  The generator itself would only have to 
provide one of the UInt types and the other would be provided by default 
implementation (either by stacking 2 UInt32s or discarding half of a UInt64).  
I know this is less minimal, but I don’t think it is actually complicated or 
hard to use. You just ask for the type that is most useful for you.


>> - I don’t like how it is so closely tied with Range.  I realize that both 
>> Int and Float work with Ranges, but other random types do not (e.g. 
>> CGVectors).  You are special casing FixedWidthInteger and 
>> BinaryFloatingPoint, which are very important… but we lose the ability to 
>> deal with other randomly generated types.
>> 
>> - Following on the previous point, I don’t like that the code for dealing 
>> with Integers/Floats is in Range.  It feels like things aren’t properly 
>> encapsulated. 
> 
> I actually agree with you, and for getting individual values prefer the form 
> `let x = Int.random(in: 1…10)`. Here’s how I got to what’s in the playground:
> 
> 1) We definitely want to be able to select a random element from a collection.
> 2) Given that, we’ll have (1…10).random() and (0..<10).random() even if those 
> aren’t what we prefer, and people will use them.
> 3) If people use that construction for integers, it will be strange to not 
> have the same facility for floating-point numbers.
> 4) Once we have the range-based capability for both, the type-based versions 
> are redundant (i.e., they can be added in the future if we decide we made the 
> wrong decision by excluding them).
> 
> You’re of course correct that a pattern of range-based random functions 
> doesn’t extend well to other types. I show on the last page a couple 
> different ways of writing those, for Bool and Data. Most of the other types 
> you’d want to create lie outside the Swift standard library, so we can’t 
> address really those here.

Right. I guess my thought is that I would like them to be able to use a 
standard creation pattern so it doesn’t vary from type to type (that is the 
whole point of “unification” in my mind).  In my own code, I have a concept of 
constraint, of which a set are passed to the object being created. This allows 
me to random create colors which look good together, etc….  I then have some 
convenience methods which just automatically create an appropriate constraint 
from a range where appropriate.  I’d really like to see something standard 
which allows for constraints other than simple ranges.

I think I would feel at least a little better if the range stuff worked for any 
type which can be put in a range…

I also feel like the focus on ranges to the exclusion of everything else is one 
of those cute things that will come back to bite us later.  My main focus is on 
random things which are presented to the user in some way, and I realize that 
is a different use-case than most programmers. Even for things like pure number 
generation, I am worried about things like sig-figs and not just range.

>> - Why bother supporting non-closed Ranges at all?  If you only allow closed 
>> ranges, then you can’t end up with an empty range. The only difference in 
>> behavior I can think of is on floating point, but I can’t think of a 
>> use-case where excluding the supremum is actually useful in any real world 
>> way.
> 
> Half-open ranges are a major use case for generating random numbers, 
> particularly when working with collections. Whenever you see that someone’s 
> written `random() % n`, that’s the half-open range 0..> - This may sound strange, but I would really like to see Bool handled as a 
>> default implementation on the generator protocol itself.  On my own version 
>> of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods which I 
>> find extremely useful.  CoinFlip just gives you a random bool, whereas you 
>> can say things like oneIn(100) to get ‘true’ roughly 1 out of every 100 
>> times you call it.  These are useful for branching randomly.  They are most 
>> useful on the source/generator itself because it is ergonomic when you need 
>> to rewind the source.
> 
> Bool is certainly a very important type to be able to randomly generate. I’m 
> not opposed to it being included in a proposal, but it’s simple 

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

[Richard Wei via swift-evolution]

Something like `#unknown` or `#undiscovered` in the pattern matching syntax 
makes complete sense.

-Richard

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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 

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

[Vladimir.S via swift-evolution]

Hi Chris, thank you for the new idea!

FWIW, after first reading, it looks like more elegant solution than "unknown case" in initial proposal. Swift's enums 
deserve powerful and flexible solution!


I really like the syntax of

switch val {
case .one: ...
case .two: ...
case #unknown: ...
}

instead of

switch val {
case .one: ...
case .two: ...
unknown case: ...
}

Also the possibility to use the #unknown in pattern matching is awesome.

Please find some comments/questions inline:

On 09.01.2018 9:54, Chris Lattner via swift-evolution wrote:
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.


Are you saying here about situation, when new case is added in non-frozen enum, but we are compiling the old code with 
absent new case but with "unknown case" in switch? As stated in proposal, in this case we'll have a warning exactly for 
source compatibility reason: "..unknown case matches any value. ... the compiler will produce a warning if all known 
elements of the enum have not already been matched. This is a warning rather than an error so that adding new elements 
to the enum remains a source-compatible change." Do you suggest to change that warning into error?


Or you are saying about another situation when “unknown case” will match known 
cases too in the initial proposal ?




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.



Are you suggesting to have this?:

switch val {
case .one: ...
case .two: ...
case #unknown: ...
default: ..
}

So, all new cases, introduced in external module after compilation of that code will fall into "case #unknown: ..." 
bucket, but all "known"(at the moment of compilation) cases but not .one/.two - into "default:..." ? Personally I like 
that, so if I need this - I will be able to express this, but that rule seems like complicated to understand.


But this can be really helpful in situation, when you *at compilation time" thinks that you are not interested in 
anything but .one/.two cases of that enum, but in case of new values - you want to show(for example) a warning for app user.




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 

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

[Cheyo Jimenez via swift-evolution]

> On Jan 9, 2018, at 10:43 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>> 
>> What is your evaluation of the proposal?
> +1 on the general problem, but I have a few comments on the design specifics
> 
> - I'd very much prefer automatic synthesis with enums, 
> - I strongly feel the compiler should auto-generate the implementation in an 
> extension for enums.
> - Should we add `ValueCollection.Index == Int` to the associatedtype so it 
> can always be indexed as in a table? 
>   - At the least, we should ensure the synthesized implementation is 
> int-indexed for tables.
> - I feel we should allow auto-generation of imported c enums in an extension, 
> as just an array of the known cases rather than the magical metadata iterator 
> if necessary. 
> 
+1 for known cases at compile time. 


>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Definitely. It's been a gaping hole in the language since the beginning.
> 
>> 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 prefer Java's automatic allValues(), but this is better than nothing.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> Followed at least the start of several threads and read the proposal.
> ___
> 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

[Chris Lattner via swift-evolution]

> On Jan 9, 2018, at 10:23 AM, Ben Cohen  wrote:
>>> 
>>> 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?  
> 
> Given it’s going to be in the ABI regardless, and has at least some marginal 
> utility, if we can find a more sensible name for it is there any strong 
> motivation to deprecate it?

+1 for renaming it to something that isn’t super confusing, but +100 for 
removing it outright.

Rationale: if we didn’t have this functionality in the stdlib today, we would 
not consider adding it.  It doesn’t meet the bar we’ve set for what is in the 
standard library.  It only exists there by historical accident.  The Mirror API 
was not carefully considered.

>> Finally, is anyone actually using this type?
>> 
> 
> IMO that isn’t a question we should be asking any more except in cases where 
> an existing implementation is causing active harm. Which, confusing name 
> aside, this type isn’t (aside from API sprawl I guess).

It directly impacts code size for applications of swift that use the standard 
library as a standard library, e.g. a raspberry pi dev situation.  It is also 
bloat, and also takes us down a slippery slope by allowing people to say “if 
that weird thing is in, why can’t I add my own narrow enhancement?”


More to the point though, this seems like an implementation detail of Mirrors.  
What is the plan for Mirrors + ABI stability?

-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 9, 2018, at 8:16 AM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> I'm not sure a valid use case by a third party makes it hold its weight for 
> inclusion in the stdlib. Reproducing its feature set is extremely trivial, 
> and would probably allow you to hint the implementation details better for 
> your use case.

Right.  The functionality can be moved out to a third party package outside the 
stdlib, or copied directly into a project that needs it (worse case).  We’re 
not removing the ability for Swift code to do this, just talking about removing 
it from the swift standard library (which has a very high bar for 
functionality).

-Chris

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

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

[Dave Abrahams via swift-evolution]

> On Jan 9, 2018, at 11:01 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> - Why bother supporting non-closed Ranges at all?  If you only allow closed 
>> ranges, then you can’t end up with an empty range. The only difference in 
>> behavior I can think of is on floating point, but I can’t think of a 
>> use-case where excluding the supremum is actually useful in any real world 
>> way.
>> 
> 
> 
> Ranges are the currency type, whereas closed ranges aren’t. We should try to 
> avoid any solution that goes against this pattern. People are going to have a 
> Range, and having to convert it into a ClosedRange just to get a random 
> number from it is confusing.
> 
> The argument goes that you want to avoid traps, therefore forbid half-open 
> range because it can be empty and might trap, whereas closed ranges doesn’t. 
> Therefore, let’s only have closed ranges. Type safety ftw. 
> 
> In practice, I don’t think this is justified. Realistically, you can divide 
> uses into two cases, literals and runtime-generated ranges.
> 
> Literals are obviously empty by inspection. It’s hard to do this by accident 
> and any kind of coverage testing of (0..<0).random() will immediately trap. 
> So probably a non-issue.
> 
> If you’re generating ranges at runtime from variables, you have another risk 
> of traps that applies just as much to closed ranges: inversion.
> 
> i.e.:
> 
> x = 5
> y = 4
> x...y // boom, can't form Range with upperBound < lowerBound
> 
> This is easily done. Nate’s example playground even had a possible case!
> 
> // better hope items always has at least 3 elements...
> let countForSale = (3...items.count).random() 
> 
> Given this is already an issue, the additional risk of trapping on empty 
> half-open ranges seems modest and acceptable to me, compared to the 
> alternative of encouraging constant banging of the result from .random() on 
> ranges.

+1


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

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

[Ben Cohen via swift-evolution]

> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> - Why bother supporting non-closed Ranges at all?  If you only allow closed 
> ranges, then you can’t end up with an empty range. The only difference in 
> behavior I can think of is on floating point, but I can’t think of a use-case 
> where excluding the supremum is actually useful in any real world way.
> 


Ranges are the currency type, whereas closed ranges aren’t. We should try to 
avoid any solution that goes against this pattern. People are going to have a 
Range, and having to convert it into a ClosedRange just to get a random number 
from it is confusing.

The argument goes that you want to avoid traps, therefore forbid half-open 
range because it can be empty and might trap, whereas closed ranges doesn’t. 
Therefore, let’s only have closed ranges. Type safety ftw. 

In practice, I don’t think this is justified. Realistically, you can divide 
uses into two cases, literals and runtime-generated ranges.

Literals are obviously empty by inspection. It’s hard to do this by accident 
and any kind of coverage testing of (0..<0).random() will immediately trap. So 
probably a non-issue.

If you’re generating ranges at runtime from variables, you have another risk of 
traps that applies just as much to closed ranges: inversion.

i.e.:

x = 5
y = 4
x...y // boom, can't form Range with upperBound < lowerBound

This is easily done. Nate’s example playground even had a possible case!

// better hope items always has at least 3 elements...
let countForSale = (3...items.count).random() 

Given this is already an issue, the additional risk of trapping on empty 
half-open ranges seems modest and acceptable to me, compared to the alternative 
of encouraging constant banging of the result from .random() on ranges.


___
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

[Kevin Nattinger via swift-evolution]

> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>  
> 
>  
> What is your evaluation of the proposal?
+1 on the general problem, but I have a few comments on the design specifics

- I'd very much prefer automatic synthesis with enums, 
- I strongly feel the compiler should auto-generate the implementation in an 
extension for enums.
- Should we add `ValueCollection.Index == Int` to the associatedtype so it can 
always be indexed as in a table? 
  - At the least, we should ensure the synthesized implementation is 
int-indexed for tables.
- I feel we should allow auto-generation of imported c enums in an extension, 
as just an array of the known cases rather than the magical metadata iterator 
if necessary. 

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Definitely. It's been a gaping hole in the language since the beginning.

> 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 prefer Java's automatic allValues(), but this is better than nothing.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed at least the start of several threads and read the proposal.___
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 10:12 PM, Chris Lattner  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?
> 

Allowing duplicate keys can be useful depending on the use case.  Though you 
could argue they shouldn’t be called keys then…

This type can be described as “just an ordered immutable list of pairs that you 
can declare using the `[:]` syntax because that looks nicer than `[(,)]`” . 
Allowing duplicate keys, and preserving declaration order, is just what it does.

One thought I had was we could replace it with conditional conformance by 
making `Array: ExpressibleByDictionaryLiteral where Element = (Key,Value)`. But 
we can’t do that quite yet, because I think it needs [parameterized 
extensions](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
 
).
 Also that might be confusing too ("huh, I can create an array from a 
dictionary literal???”).

> 
> 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?
> 

Because it’s currently in user-declared order, like an array. I don’t think we 
could change that without breaking any code that uses it for what it does 
today. Here’s an example in the wild that is reliant on preserving order:
https://github.com/apple/swift/blob/master/benchmark/single-source/RomanNumbers.swift#L28
 
.

We will hopefully add a value-type sorted dictionary too, at some point, which 
would cover the sorted literal use case.

> 
>> 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?  

Given it’s going to be in the ABI regardless, and has at least some marginal 
utility, if we can find a more sensible name for it is there any strong 
motivation to deprecate it?

> That avoids it being an ABI concern, because we could make it be force 
> inlined into any client code.
> 

"we could make it be force inlined into any client code” isn’t a feature we 
currently plan on having unfortunately. Also this is a type rather than just a 
method, so we’d need a feature to always emit the symbol into the client too.

> Finally, is anyone actually using this type?
> 

IMO that isn’t a question we should be asking any more except in cases where an 
existing implementation is causing active harm. Which, confusing name aside, 
this type isn’t (aside from API sprawl I guess).

> -Chris
> 
> 
> 

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

[Daniel Steinberg via swift-evolution]

> 
> What is your evaluation of the proposal?
+1 it’s something I often hack myself
> 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 - I think it will encourage the use of enumerations in more places where 
they are appropriate
> 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?
A quick reading and followed the issue when it came up before. 
> 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-0194: Derived Collection of Enum Cases

[Riley Testut via swift-evolution]

I’m overall +1, but I’m curious: would you be able to conform an enum from 
another module to ValueEnumerable via an extension, and still have the compiler 
generate the protocol requirements for you? I can imagine that the client of a 
framework with an enum may have a valid use for iterating over all values that 
the author didn’t foresee, and I would very much like the client to be able to 
opt-in to the compiler code generation.

(Personally, I’d prefer that all simple enums automatically conform to the 
protocol and have automatic implementations, since I don’t really see a 
downside to this that exists for some other compiler-magic protocols like 
Codable)

> On Jan 9, 2018, at 8:45 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
>> On Mon, Jan 8, 2018 at 11: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?
> Big +1. I've been looking forward to something like this for a long time.
> 
> I'm extremely happy with the API chosen here. ValueEnumerable and allValues 
> are absolutely the correct names, because the protocol is not *restricted* to 
> enums, it is merely *synthesized automatically* for enums. That's a very 
> important distinction. Someone could provide their own conformance to 
> ValueEnumerable and use it in generic algorithms and have everything work as 
> expected.
> 
> In a perfect world I would argue that the associated type of allValues should 
> be a Sequence instead of a Collection as this would allow it to be extended 
> to infinite sequences (i.e., cases with associated values that are deeply 
> ValueEnumerable), but I'll admit that I've never come up with a compelling 
> use case for this beyond obscure combinatorial algorithms. Since getting the 
> count of values is important to many users, Collection is a reasonable 
> compromise and I don't have any objections.
>  
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes. It's a frequently requested feature and has utility both in UI-driven 
> logic (table view sections based on an enum) and other algorithms.
> 
>  
>> Does this proposal fit well with the feel and direction of Swift?
> Yes. The API design fits right into other stdlib concepts, and the conditions 
> for synthesis align with the synthesis of other synthesized protocols.
> 
>  
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> Just Java's values() function that is present on all enums. The functionality 
> provided here is what I would expect, similar to other languages.
> 
>  
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> An in-depth read and I was heavily involved in some of the earlier discussion 
> threads.
> 
>  
>> 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
___
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 à 18:18, Nate Cook  a écrit :
> 
>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>>> 
>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>>> > a écrit :
>>> 
>>> I'm not sure a valid use case by a third party makes it hold its weight for 
>>> inclusion in the stdlib.
>> 
>> You're definitely right, and that's why I wrote with the most humble tone I 
>> could.
>> 
>> Yet, the design of the stdlib *requires* some speculation about use cases, 
>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>> readers of the mailing list had any idea of the use cases of the current 
>> DictionaryLiteral, and maybe I helped a little.
>> 
>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>> you to hint the implementation details better for your use case.
>> 
>> Please define "trivial”.
>> 
>> In case anybody would wonder, in the line below the `row` variable is of 
>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of 
>> type DictionaryLiteral. The use case here is the ability to express a row 
>> with a dictionary literal that accepts duplicated keys and preserves 
>> ordering:
>> 
>>  XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
> “dictionary literal”, which no one is suggesting we remove.

You're right ! I was almost sure that ExpressibleByDictionaryLiteral 
initializer would eat a DictionaryLiteral, but it doesn't!

extension Row : ExpressibleByDictionaryLiteral {
init(dictionaryLiteral elements: (String, 
DatabaseValueConvertible?)...) { ... }
}

This code has been written too long ago. I have been mislead, I'd like to 
apologize.

> If I’m understanding what you wrote, this is another case where the terrible 
> name is making it super hard to discuss what we’re talking about. “Dictionary 
> literals” and the ExpressibleByDictionaryLiteral protocol are safe!

Yes, I have been bitten hard by the names! Time for bikeshedding indeed :-)

Gwendal

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

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

[Eneko Alonso via swift-evolution]

Now that I think of it, this type would be great for storing results from a SQL 
query run on a database, for instance.

This is a valid SQL statement:

SELECT `firstname`, `lastname`, `firstname` FROM `employees`;

Note there is two copies of “firstname”. Don’t ask why. All that matters is 
that is valid SQL and that storing the results on a Dictionary wouldn’t be 
possible without manipulation.

Thus, using DictionaryLiteral (aka TableRow) would make much sense. Users could 
then convert to a Dictionary with the new unifyingKeys initializer, or 
“deserialize” into custom models that can be initialized with the TableRow 
(maybe via Decodable).

Given a proper name, this type could be really useful in many cases.

Thanks,
Eneko


> On Jan 9, 2018, at 9:28 AM, Eneko Alonso via swift-evolution 
>  wrote:
> 
> How about renaming DictionaryLiteral to Row, TabularRow or TableRow?
> 
> I think most developers are familiar with the idea that a table row contains 
> multiple columns (in specific order), and each column has a name and a value 
> (key/value).
> 
> Some other name suggestions:
> - Record (kind of an old name for table rows)
> - SortedDictionary (sorted dictionaries are missing on the standard library, 
> and could give a chance to make this type more widely used)
> 
> 
> Thanks,
> Eneko 
> 
> 
> 
> 
>> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>> > wrote:
>> 
>>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>>> > wrote:
>>> 
 
 Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
 > a écrit :
 
 I'm not sure a valid use case by a third party makes it hold its weight 
 for inclusion in the stdlib.
>>> 
>>> You're definitely right, and that's why I wrote with the most humble tone I 
>>> could.
>>> 
>>> Yet, the design of the stdlib *requires* some speculation about use cases, 
>>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>>> readers of the mailing list had any idea of the use cases of the current 
>>> DictionaryLiteral, and maybe I helped a little.
>>> 
 Reproducing its feature set is extremely trivial, and would probably allow 
 you to hint the implementation details better for your use case.
>>> 
>>> Please define "trivial”.
>>> 
>>> In case anybody would wonder, in the line below the `row` variable is of 
>>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not 
>>> of type DictionaryLiteral. The use case here is the ability to express a 
>>> row with a dictionary literal that accepts duplicated keys and preserves 
>>> ordering:
>>> 
>>> XCTAssertEqual(row, ["a": 1, "a": 2])
>> 
>> That’s great! In this case you aren’t using the DictionaryLiteral type, but 
>> a “dictionary literal”, which no one is suggesting we remove. If I’m 
>> understanding what you wrote, this is another case where the terrible name 
>> is making it super hard to discuss what we’re talking about. “Dictionary 
>> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
>> 
>>> I don't see how anything could better fit this use case than the current 
>>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>>> that wants to model database rows beyond the traditional (and ill-advised) 
>>> dictionary.
>>> 
>>> Some other users may come with other use cases that may also help the 
>>> stdlib designers choose the best solution.
>>> 
>>> Gwendal
>>> 
 
 Zach
 z...@waldowski.me 
 
 
 On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
> 
>> 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:
> 
>> 

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

[Eneko Alonso via swift-evolution]

How about renaming DictionaryLiteral to Row, TabularRow or TableRow?

I think most developers are familiar with the idea that a table row contains 
multiple columns (in specific order), and each column has a name and a value 
(key/value).

Some other name suggestions:
- Record (kind of an old name for table rows)
- SortedDictionary (sorted dictionaries are missing on the standard library, 
and could give a chance to make this type more widely used)


Thanks,
Eneko 




> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>  wrote:
> 
>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>>> 
>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>>> > a écrit :
>>> 
>>> I'm not sure a valid use case by a third party makes it hold its weight for 
>>> inclusion in the stdlib.
>> 
>> You're definitely right, and that's why I wrote with the most humble tone I 
>> could.
>> 
>> Yet, the design of the stdlib *requires* some speculation about use cases, 
>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>> readers of the mailing list had any idea of the use cases of the current 
>> DictionaryLiteral, and maybe I helped a little.
>> 
>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>> you to hint the implementation details better for your use case.
>> 
>> Please define "trivial”.
>> 
>> In case anybody would wonder, in the line below the `row` variable is of 
>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of 
>> type DictionaryLiteral. The use case here is the ability to express a row 
>> with a dictionary literal that accepts duplicated keys and preserves 
>> ordering:
>> 
>>  XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
> “dictionary literal”, which no one is suggesting we remove. If I’m 
> understanding what you wrote, this is another case where the terrible name is 
> making it super hard to discuss what we’re talking about. “Dictionary 
> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
> 
>> I don't see how anything could better fit this use case than the current 
>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>> that wants to model database rows beyond the traditional (and ill-advised) 
>> dictionary.
>> 
>> Some other users may come with other use cases that may also help the stdlib 
>> designers choose the best solution.
>> 
>> Gwendal
>> 
>>> 
>>> Zach
>>> z...@waldowski.me 
>>> 
>>> 
>>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
 
> 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 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

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

[Nate Cook via swift-evolution]

> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
>> 
>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>> > a écrit :
>> 
>> I'm not sure a valid use case by a third party makes it hold its weight for 
>> inclusion in the stdlib.
> 
> You're definitely right, and that's why I wrote with the most humble tone I 
> could.
> 
> Yet, the design of the stdlib *requires* some speculation about use cases, 
> and speculation is *helped* by the exposition of actual uses. I'm not sure 
> readers of the mailing list had any idea of the use cases of the current 
> DictionaryLiteral, and maybe I helped a little.
> 
>> Reproducing its feature set is extremely trivial, and would probably allow 
>> you to hint the implementation details better for your use case.
> 
> Please define "trivial”.
> 
> In case anybody would wonder, in the line below the `row` variable is of type 
> Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of type 
> DictionaryLiteral. The use case here is the ability to express a row with a 
> dictionary literal that accepts duplicated keys and preserves ordering:
> 
>   XCTAssertEqual(row, ["a": 1, "a": 2])

That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
“dictionary literal”, which no one is suggesting we remove. If I’m 
understanding what you wrote, this is another case where the terrible name is 
making it super hard to discuss what we’re talking about. “Dictionary literals” 
and the ExpressibleByDictionaryLiteral protocol are safe!

> I don't see how anything could better fit this use case than the current 
> DictionaryLiteral. This is not *my* use case, but the use case of anyone that 
> wants to model database rows beyond the traditional (and ill-advised) 
> dictionary.
> 
> Some other users may come with other use cases that may also help the stdlib 
> designers choose the best solution.
> 
> Gwendal
> 
>> 
>> Zach
>> z...@waldowski.me 
>> 
>> 
>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>>> 
 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 
>>> 
>> 
>> ___
>> 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] [swift-corelibs-dev] Discourse rollout re-schedule

[Lars Sonchocky-Helldorf via swift-evolution]

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

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

[Gwendal Roué via swift-evolution]

> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>  a écrit :
> 
> I'm not sure a valid use case by a third party makes it hold its weight for 
> inclusion in the stdlib.

You're definitely right, and that's why I wrote with the most humble tone I 
could.

Yet, the design of the stdlib *requires* some speculation about use cases, and 
speculation is *helped* by the exposition of actual uses. I'm not sure readers 
of the mailing list had any idea of the use cases of the current 
DictionaryLiteral, and maybe I helped a little.

> Reproducing its feature set is extremely trivial, and would probably allow 
> you to hint the implementation details better for your use case.

Please define "trivial".

In case anybody would wonder, in the line below the `row` variable is of type 
Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of type 
DictionaryLiteral. The use case here is the ability to express a row with a 
dictionary literal that accepts duplicated keys and preserves ordering:

XCTAssertEqual(row, ["a": 1, "a": 2])

I don't see how anything could better fit this use case than the current 
DictionaryLiteral. This is not *my* use case, but the use case of anyone that 
wants to model database rows beyond the traditional (and ill-advised) 
dictionary.

Some other users may come with other use cases that may also help the stdlib 
designers choose the best solution.

Gwendal

> 
> Zach
> z...@waldowski.me 
> 
> 
> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>> 
>>> 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 
>> 
> 
> ___
> 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

[Jon Gilbert via swift-evolution]

Having reviewed much of the commentary on this proposal, I keep coming back to 
the same thought: why not use @versioned and @available keywords for this 
instead of some concept related to “exhaustive”?

The issue here is not whether a given enum is “exhaustive” over the enumerated 
problem space; it’s whether the developer wants to alter the enum in the future 
without breaking ABI compatibility.

If you call it “exhaustive” then it’s misleading, because all enums at a given 
moment in time can be switched over exhaustively. This will just confuse folks.

Since versioning is really the main goal, why not use the same annotations for 
versioning enums as are used for versioning everything else?

@versioned
enum MyError: Error {
@available(OSX, deprecated:10.11, message: "this error case is going away in 
10.12")
case BadThingHappened

@available(forever)
case ReallyBadThingHappened
}

etc.

That way you could have some cases get removed in the future as well as added, 
and you won’t confuse people by talking about “complete” or “exhaustive”, which 
are terms that are too closely coupled with the meaning and application of a 
given enum to which they refer. 

It would be best to use terms that just say what they mean. We are talking 
about versioning APIs to keep ABI stability? Use @versioned and @available like 
everywhere else. 

Or is there a compelling reason this cannot be done? I read much of the 
arguments here but didn’t see any mention of @versioned... maybe it’s iOS Mail 
app thinking I was looking for an email address that contains @versioned? ;D

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

[Tony Allevato via swift-evolution]

On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> 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?
>
> Big +1. I've been looking forward to something like this for a long time.

I'm extremely happy with the API chosen here. ValueEnumerable and allValues
are absolutely the correct names, because the protocol is not *restricted*
to enums, it is merely *synthesized automatically* for enums. That's a very
important distinction. Someone could provide their own conformance to
ValueEnumerable and use it in generic algorithms and have everything work
as expected.

In a perfect world I would argue that the associated type of allValues
should be a Sequence instead of a Collection as this would allow it to be
extended to infinite sequences (i.e., cases with associated values that are
deeply ValueEnumerable), but I'll admit that I've never come up with a
compelling use case for this beyond obscure combinatorial algorithms. Since
getting the count of values is important to many users, Collection is a
reasonable compromise and I don't have any objections.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes. It's a frequently requested feature and has utility both in UI-driven
logic (table view sections based on an enum) and other algorithms.



>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes. The API design fits right into other stdlib concepts, and the
conditions for synthesis align with the synthesis of other synthesized
protocols.



>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> Just Java's values() function that is present on all enums. The
functionality provided here is what I would expect, similar to other
languages.



>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> An in-depth read and I was heavily involved in some of the earlier
discussion threads.



> 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

[Nate Cook via swift-evolution]

> On Jan 9, 2018, at 4:12 AM, Jonathan Hull  wrote:
> 
> Some thoughts:
> 
> - How do I randomly select an enum?

Vote for SE-0194! :)

> - I like that RandomNumberGenerator doesn’t have an associated type. I agree 
> that we should just spit out UInt64s for simplicity.

It simplifies things a lot, at some performance cost. For example, the LCRNG 
type really produces UInt32s, so I have to use two of its outputs to generate 
one value, even if I don’t need that many bits.

> - I don’t like how it is so closely tied with Range.  I realize that both Int 
> and Float work with Ranges, but other random types do not (e.g. CGVectors).  
> You are special casing FixedWidthInteger and BinaryFloatingPoint, which are 
> very important… but we lose the ability to deal with other randomly generated 
> types.
> 
> - Following on the previous point, I don’t like that the code for dealing 
> with Integers/Floats is in Range.  It feels like things aren’t properly 
> encapsulated. 

I actually agree with you, and for getting individual values prefer the form 
`let x = Int.random(in: 1…10)`. Here’s how I got to what’s in the playground:

1) We definitely want to be able to select a random element from a collection.
2) Given that, we’ll have (1…10).random() and (0..<10).random() even if those 
aren’t what we prefer, and people will use them.
3) If people use that construction for integers, it will be strange to not have 
the same facility for floating-point numbers.
4) Once we have the range-based capability for both, the type-based versions 
are redundant (i.e., they can be added in the future if we decide we made the 
wrong decision by excluding them).

You’re of course correct that a pattern of range-based random functions doesn’t 
extend well to other types. I show on the last page a couple different ways of 
writing those, for Bool and Data. Most of the other types you’d want to create 
lie outside the Swift standard library, so we can’t address really those here.

> - Why bother supporting non-closed Ranges at all?  If you only allow closed 
> ranges, then you can’t end up with an empty range. The only difference in 
> behavior I can think of is on floating point, but I can’t think of a use-case 
> where excluding the supremum is actually useful in any real world way.

Half-open ranges are a major use case for generating random numbers, 
particularly when working with collections. Whenever you see that someone’s 
written `random() % n`, that’s the half-open range 0.. - This may sound strange, but I would really like to see Bool handled as a 
> default implementation on the generator protocol itself.  On my own version 
> of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods which I 
> find extremely useful.  CoinFlip just gives you a random bool, whereas you 
> can say things like oneIn(100) to get ‘true’ roughly 1 out of every 100 times 
> you call it.  These are useful for branching randomly.  They are most useful 
> on the source/generator itself because it is ergonomic when you need to 
> rewind the source.

Bool is certainly a very important type to be able to randomly generate. I’m 
not opposed to it being included in a proposal, but it’s simple enough to do on 
your own that it didn’t pass the “minimal” test that I was using in the 
playground. You could use something like this static method:

extension Bool {
static func random(
probability: Double = 0.5, 
using generator: RandomNumberGenerator = Random.default
) {
return (0.0 ..< 1.0).random(using: generator) < probability
}
}

I don’t think there should be any value-producing methods on generators—most 
users shouldn’t need to think about generators at all, and the ones who have a 
specific need (repeatability, rewinding, etc) should be able to use the same 
APIs as the people who aren’t thinking about them.

> - IMO distributions should be sources/generators themselves which just wrap 
> another source.  We could have a subprotocol of RandomNumberGenerator which 
> just semantically guarantees uniform distribution, and then distributions 
> that need it could be sure of the input distribution.  Notice this doesn’t 
> limit the distribution to only be used for Integers as they are in the demo. 
> They can be used anywhere a source can be used.

I’d really like to maintain a clear line between generators and distributions 
(which I don’t think we need an additional protocol for). Distributions create 
values of a specific kind of type, with a particular distribution, which 
usually isn't suitable to use as the input for another algorithm that needs 
random data. Generators just pump out (hopefully) uniformly distributed bits, 
which distributions and other algorithms can then interpret and shape.

> - Having a subprotocol for generators which can be rewound is extremely 
> important for entire classes of real-world problems.  I have spent a lot of 
> time using 

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

[Dave DeLong via swift-evolution]

> On Jan 9, 2018, at 3:12 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Some thoughts:
> 
> - How do I randomly select an enum?

Well… combine this with SE-0194 and you have all the basics you need: the set 
of all enum values in a collection, and a way to pick a random element from a 
collection...

> 
> - I like that RandomNumberGenerator doesn’t have an associated type. I agree 
> that we should just spit out UInt64s for simplicity.
> 
> - I don’t like how it is so closely tied with Range.  I realize that both Int 
> and Float work with Ranges, but other random types do not (e.g. CGVectors).  
> You are special casing FixedWidthInteger and BinaryFloatingPoint, which are 
> very important… but we lose the ability to deal with other randomly generated 
> types.
> 
> - Following on the previous point, I don’t like that the code for dealing 
> with Integers/Floats is in Range.  It feels like things aren’t properly 
> encapsulated. 
> 
> - Why bother supporting non-closed Ranges at all?  If you only allow closed 
> ranges, then you can’t end up with an empty range. The only difference in 
> behavior I can think of is on floating point, but I can’t think of a use-case 
> where excluding the supremum is actually useful in any real world way.
> 
> - This may sound strange, but I would really like to see Bool handled as a 
> default implementation on the generator protocol itself.  On my own version 
> of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods which I 
> find extremely useful.  CoinFlip just gives you a random bool, whereas you 
> can say things like oneIn(100) to get ‘true’ roughly 1 out of every 100 times 
> you call it.  These are useful for branching randomly.  They are most useful 
> on the source/generator itself because it is ergonomic when you need to 
> rewind the source.
> 
> - IMO distributions should be sources/generators themselves which just wrap 
> another source.  We could have a subprotocol of RandomNumberGenerator which 
> just semantically guarantees uniform distribution, and then distributions 
> that need it could be sure of the input distribution.  Notice this doesn’t 
> limit the distribution to only be used for Integers as they are in the demo. 
> They can be used anywhere a source can be used.
> 
> - Having a subprotocol for generators which can be rewound is extremely 
> important for entire classes of real-world problems.  I have spent a lot of 
> time using this and it solves a LOT of problems. For example, I have a Lorem 
> Ipsum Generator which takes Attributes and a CGSize to fill.  It works by 
> branching (using the Bool methods above) and then rewinding bits which don’t 
> fit (If you just futz with the last part instead of generating appropriate 
> clauses, it won’t look right).  I also have a bunch of backtracking 
> algorithms which rely on this rewind ability.  Plus numerous visual effects 
> which rely on a repeatable rewindable source.
>   - Tl;dr: It isn’t enough to just have a seed, you need to be able to 
> mark a state of a generator and return to that state later.
> 
>   My RepeatableRandomSource Protocol has 3 extra methods:
>   - It takes a seed
>   - It has a mark() method which returns a token
>   - It has a returnToMark(_ mark:Mark) method which takes a token and 
> restores the appropriate state 
> 
> - I really appreciate that you made a playground :-)
> 
> Thanks,
> Jon
> 
> 
>> On Jan 8, 2018, at 11:02 AM, 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 

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

[Xiaodi Wu via swift-evolution]

On Tue, Jan 9, 2018 at 05:12 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Some thoughts:
>
> - How do I randomly select an enum?
>
> - I like that RandomNumberGenerator doesn’t have an associated type. I
> agree that we should just spit out UInt64s for simplicity.
>
> - I don’t like how it is so closely tied with Range.  I realize that both
> Int and Float work with Ranges, but other random types do not (e.g.
> CGVectors).  You are special casing FixedWidthInteger and
> BinaryFloatingPoint, which are very important… but we lose the ability to
> deal with other randomly generated types.
>

So, I’ll defend this design. At some point, you need to expose the
primitive operation, which is the selection of a random *number* within a
range, and after our very lengthy discussions, this is the best spelling in
Swift by consensus.

- Following on the previous point, I don’t like that the code for dealing
> with Integers/Floats is in Range.  It feels like things aren’t properly
> encapsulated.
>
> - Why bother supporting non-closed Ranges at all?  If you only allow
> closed ranges, then you can’t end up with an empty range. The only
> difference in behavior I can think of is on floating point, but I can’t
> think of a use-case where excluding the supremum is actually useful in any
> real world way.
>

This is a nontrivial thing to get right; in fact, in C++, many
implementations of the standard library got it wrong for quite some time.
Additionally, generating a value in 0..<1 is a primitive operation which is
equivalent, essentially, to generating a random significand, so it is
important to expose this functionality in the standard library.

- This may sound strange, but I would *really* like to see Bool handled as
> a default implementation on the generator protocol itself.  On my own
> version of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods
> which I find extremely useful.  CoinFlip just gives you a random bool,
> whereas you can say things like oneIn(100) to get ‘true’ roughly 1 out of
> every 100 times you call it.  These are useful for branching randomly.
> They are most useful on the source/generator itself because it is ergonomic
> when you need to rewind the source.
>

This is a Bernoulli distribution. Which is a trivial distribution to
implement—if you have a primitive that gives you a random value in the
range 0..<1! (See, this is why you need that as a primitive.) Then, for
example, a fair coin is obtained by binning 0..<0.5 as heads and 0.5..<1 as
tails. Adjust to taste for your desired value of p.

However, more below on distributions.

- IMO distributions should be sources/generators themselves which just wrap
> another source.  We could have a subprotocol of RandomNumberGenerator which
> just semantically guarantees uniform distribution, and then distributions
> that need it could be sure of the input distribution.  Notice this doesn’t
> limit the distribution to only be used for Integers as they are in the
> demo. They can be used anywhere a source can be used.
>

One of the major critiques of the C++ design is its overcomplicated design,
one aspect of which is this wrapping of sources. Some people might like it
or find it to be their preferred design, but given that there’s some
consensus that the uniform distribution is all we’re offering in the
standard library (with everything else being more appropriate for a
third-party library that’s more elaborate), this is a design decision that
each such third-party library can decide for itself.

- Having a subprotocol for generators which can be rewound is extremely
> important for entire classes of real-world problems.  I have spent a lot of
> time using this and it solves a LOT of problems. For example, I have a
> Lorem Ipsum Generator which takes Attributes and a CGSize to fill.  It
> works by branching (using the Bool methods above) and then rewinding bits
> which don’t fit (If you just futz with the last part instead of generating
> appropriate clauses, it won’t look right).  I also have a bunch of
> backtracking algorithms which rely on this rewind ability.  Plus numerous
> visual effects which rely on a repeatable rewindable source.
> *- Tl;dr: It isn’t enough to just have a seed, you need to be able to mark
> a state of a generator and return to that state later.*
>
> My RepeatableRandomSource Protocol has 3 extra methods:
> - It takes a seed
> - It has a mark() method which returns a token
> - It has a returnToMark(_ mark:Mark) method which takes a token and
> restores the appropriate state
>

This too is one of those features that, given how we’re not offering any
such RNGs in the standard library, can be a decision for custom libraries
to design in a way that most suits themselves. Many RNGs can be seeded and
reseeded, but not all can be rewound or skipped ahead, so it’s something
where the ultimate hierarchy of protocols and their methods will depend on
the concrete types on offer.

- I really 

Re: [swift-evolution] Renaming SwiftObject

[Saagar Jha via swift-evolution]

Well, there’s always the option of Swift._NonObjcSwiftObject…but to be honest 
what this class looks like from the Swift side is much less of a concern to me. 
Getting “Swift” in the mangled name is probably good enough.

Saagar Jha

> On Jan 8, 2018, at 15:00, Greg Parker  wrote:
> 
> 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