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

[Martin Waitz via swift-evolution]

Hello Brent,

> Am 10.01.2018 um 06:15 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> 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.

A conditional conformance for Optional could in fact be useful, but what’s the 
use-case for Bool?
If somebody needs a Bool conformance for generic code, it’s extremely simple to 
just define conformance herself.
If we see that people really do need Bool conformance, we can still add it at 
any time.

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

I would start with the default initialiser.

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

Re: [swift-evolution] Incremental ABI stability

[Ted Kremenek via swift-evolution]

Hi Nevin,

I think it is important to separate the issues of concern here, as I think too 
much is get conflated into one topic.  ABI stability doesn’t mean that the 
language or Standard Library can’t change in the future.  It *does* mean we 
can’t just remove APIs wholesale that clients may depend on today, but I feel 
we are already in that place with the Standard Library.  For the Standard 
Library, ABI stability brings promises for binary compatibility for future 
versions of the Standard Library to clients that link against it — but that 
doesn’t mean that APIs can’t be deprecated and/or phased out in practice and 
new ones introduced.  For example, with Mirror, we may need to keep the 
existing Mirror APIs in place for existing clients that depend on them, but 
that doesn’t mean we couldn’t introduce better alternatives to Mirror in the 
future.

When talking about what ABI stability means, I think it is important to be 
technically specific about what it means and what it doesn’t mean.  For 
example, the wording you chose here was “still be able to fix the parts that we 
can already see need fixing” as if ABI stability would prevent you from doing 
that.  It is true that ABI stability means we can’t make certain kinds of 
changes — that’s what the “stability” of ABI stability means — but for the 
Standard Library ABI stability more-or-less brings the same kind of mental 
model for stability that most clients expect out of stable libraries these 
days: APIs can evolve, new ones can be added, and old ones can be 
deprecated/phased out, but existing clients that depend on the old interfaces 
need to continue to work.  That model is not incompatible with “fixing” APIs; 
it just means that “fixing” takes on different forms than just wholesale 
ripping out old APIs and replacing them with totally different ones.  We’re 
rapidly moving past that point with the evolution of the Standard Library 
anyway, and I think that’s something worth keeping in mind.

I’m totally open to considering “carving out specific exemptions to ABI 
stability” — I think specific arguments could be made here.  But I think those 
should be technically well considered on a case-by-case basis, and not just 
fear that ABI stability will lock us into bad APIs permanently.  Even outside 
of the current APIs we feel today might be imperfect, inevitably down the road 
we’re going to look back at some APIs and say that we wish we did them 
differently and find ways to phase in changes/improvements if the need is great.

Ted

> 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] Handling unknown cases in enums [RE: SE-0192]

[Jean-Daniel via swift-evolution]

Let say you have a module that declare a enum and also declare a function that 
take that enum as parameter and switch over it.

As there is no cross module boundary, the switch don’t require #unknown or any 
fancy trick to be exhaustive.

Now if you remove the case from the enum, any client code that call your 
function by passing the enum will cause a crash.

The following is just blind guess as I don’t have any knowledge of the swift 
compiler, but as Swift cases are not necessarily simple Int, maybe there some 
times swift has to generates symbols for complex cases.
In such case, removing an enum will be even more harmful as it will cause a 
crash a start for missing symbol (assuming at such time Apple did switch to 
dyld3 which bound at launch and not lazily).


> Le 11 janv. 2018 à 01:34, Howard Lovatt  a écrit :
> 
> If an enum isn’t final; then what’s the difference in deleting as opposed to 
> adding?
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>> 
>> 
>> 
>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>>  a écrit :
>>> 
>>> Two points:
>>> 
>>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>>> distinct from default. 
>>> 
>>> 2. All the discussion is about a framework adding a case, what about when a 
>>> framework deletes a case?
>> 
>> This is a binary breaking change (just like removing an existing function or 
>> method).
>> 
>> 

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

[Howard Lovatt via swift-evolution]

It is a two way street though. An app compiled against an old framework might 
pass a deleted enum case back to the new framework that has been changed under 
it. 

Just as the app has to guard against new cases the framework has to guard 
against old cases!

Both ends need an unknown case. 

-- Howard. 

> On 10 Jan 2018, at 5:40 pm, Jordan Rose  wrote:
> 
> Remember, the goal here is to support both binary and source compatibility. 
> An existing app might be using the enum case that you're trying to remove, 
> but there's no chance that an existing app is using an enum case that you're 
> trying to add.
> 
> Jordan
> 
> 
>> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution 
>>  wrote:
>> 
>> If an enum isn’t final; then what’s the difference in deleting as opposed to 
>> adding?
>> 
>> -- Howard. 
>> 
>>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>>> 
>>> 
>>> 
 Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
  a écrit :
 
 Two points:
 
 1. I like Chris’s suggestion of #unknown and in particular that it is 
 distinct from default. 
 
 2. All the discussion is about a framework adding a case, what about when 
 a framework deletes a case?
>>> 
>>> This is a binary breaking change (just like removing an existing function 
>>> or method).
>>> 
>>> 
>> ___
>> 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]

[Goffredo Marocchi via swift-evolution]

I am sorry, but I have to disagree here. Having two separate proposals would 
make it highly more likely that one thing is done and the other one postponed 
and postponed until it seems no longer relevant in the grand scheme of 
things... first we lost labels in callbacks / stores functions (has there been 
at least some Core Team chat about this after last year?) and now we are losing 
compiler enforced exhaustive switching over enum... not only that, until we 
improve diagnostic and at least warn users we are now even behind Objective-C 
as compiler can enforce exhaustive switching and actually mandate no default 
case for enums through a compiler warning.

Sent from my iPhone

> On 11 Jan 2018, at 04:31, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
>> 
 
 - 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.
>> 
>> Notify, yes. Error, no. It's a design goal that adding a new case does not 
>> break source compatibility in addition to not breaking binary compatibility 
>> (because people don't like editing their dependencies) and therefore the 
>> behavior has to be defined when they recompile with no changes.
>> 
> 
> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
> “unknown default:” and it should have semantics basically aligned with the 
> design you laid out in the revision of the proposal.  If this is supposed to 
> be an error, then it should be a pattern production.
> 
> Do you have a sense for whether this is what people want?  We really should 
> have a review cycle evaluating exactly this sort of tradeoff.
> 
> In any case, I’ve said this before off-list, but I find this whole discussion 
> (of how to improve diagnostics for unknown cases) to be separable from the 
> core issue required to get to ABI stability.  It seems to me that we could 
> split this (ongoing) design discussion off into a separate SE, allowing you 
> to get on with the relatively uncontroversial and critical parts in SE-0192.
> 
> -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]

[Chris Lattner via swift-evolution]

> On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
> 
>>> 
>>> - 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.
> 
> Notify, yes. Error, no. It's a design goal that adding a new case does not 
> break source compatibility in addition to not breaking binary compatibility 
> (because people don't like editing their dependencies) and therefore the 
> behavior has to be defined when they recompile with no changes.
> 

Ok, if that’s the desired design, then (IMO) the right way to spell it is 
“unknown default:” and it should have semantics basically aligned with the 
design you laid out in the revision of the proposal.  If this is supposed to be 
an error, then it should be a pattern production.

Do you have a sense for whether this is what people want?  We really should 
have a review cycle evaluating exactly this sort of tradeoff.

In any case, I’ve said this before off-list, but I find this whole discussion 
(of how to improve diagnostics for unknown cases) to be separable from the core 
issue required to get to ABI stability.  It seems to me that we could split 
this (ongoing) design discussion off into a separate SE, allowing you to get on 
with the relatively uncontroversial and critical parts in SE-0192.

-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

[Chris Lattner via swift-evolution]

Brent, thanks for the detailed response, one question about it:

> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> But that's beside the point. What I think the "`allValues` should be allowed 
> to be infinite" suggestion misses is that one of `ValueEnumerable`'s 
> semantics is that it's not only theoretically *possible* to enumerate all the 
> values, but actually *reasonable* to do so.
...
> Some types, of course, fall into a gray area. `Int8` is fairly reasonable, 
> but larger integer types get increasingly unreasonable until, by `Int64`, we 
> reach types that would take decades to enumerate. Where the line should be 
> drawn is a matter of opinion. (My opinion, to be clear, is that we shouldn't 
> conform any of them; if someone really wants to do it, they can add a 
> retroactive conformance.)

I’m not sure which way you’re arguing here, but that’s ok. :-)

In my opinion, while I can see where you are coming from (that it could be 
“reasonable” to allow random types to be ValueEnumerable) I don’t see what the 
*utility* or *benefit* that would provide.

If we went with a simpler design - one that named this CaseEnumerable and 
.allCases - we would be heavily biasing the design of the feature towards 
enum-like applications that do not have associated types.  This is “the” 
problem to be solved in my opinion, and would lead to a more clear and 
consistently understood feature that doesn’t have the ambiguity and “gray 
areas” that you discuss above.  Given this bias, it is clear that infinite 
sequences are not interesting.

Of course it would certainly be *possible* for someone to conform a 
non-enum-like type to CaseEnumerable, but that would be an abuse of the 
feature, and not a "gray area”.  


Is there some specific *utility* and *benefit* from creeping this feature 
beyond “enumerating cases in enums that don’t have associated types”?  Is that 
utility and benefit large enough to make it worthwhile to water down the 
semantics of this protocol by making it so abstract?

-Chris

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree.
>
> If there should be an API to produce a random Double without parameters
> then IMHO it should simply be a uniformly distributed Double in the unit
> range [0, 1). Very useful as a basic building block and can be constructed
> very fast from a random bitpattern like eg:
> extension Double {
> init(unitRange v: UInt64) {
> self = Double(v >> Double.exponentBitCount) * (.ulpOfOne/2.0)
> }
> }
>

The implementation of randomness for floating point types deserves in-depth
consideration. I know that we have some IEEE-754 experts on this list, and
it would be great to have them weigh in. For instance…

When generating a uniformly-distributed floating point number in a
half-open range with finite bounds, should every representable value in
that range be possible to produce? If so, should each representable value v
appear with probability proportional to (v.nextUp - v), which may be
different from (x.ulp)?

In other words, conceptually, should the API behave as if a real number
were chosen uniformly from the range, then rounded down to the closest
representable value that does not exceed it?

Or should some fixed number of equally-spaced values that span the range be
the only possible results?

Or something else?

Should subnormal values be producible?

There is no uniform distribution over an infinite-length continuum, so how
should infinite ranges be handled? In the range (0.0 ..< .infinity) should
we always return .greatestFiniteMagnitude? And in (-.infinity ..< 0.0)
should we always return (-.infinity)? What about (-.infinity ..<
.infinity)? Should there be preconditions that can fail at runtime, or
should we sometime return .nan, or what?

• • •

These are just a few of the questions that spring to mind, so I think it is
highly important that floating-point randomness gets sufficient attention
to ensure that we land on a well-considered design.

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

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

[Xiaodi Wu via swift-evolution]

On Wed, Jan 10, 2018 at 5:06 AM, Brent Royal-Gordon 
wrote:

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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.
>
>
> I can't speak for the other co-authors, but for my part, this was an
> oversight and I apologize for it. I think we should have discussed your
> `MyType.self` alternative.
>
> I won't rehash the entire discussion in previous threads, but to summarize
> my objections:
>

I appreciate the detailed reply below. Time constraints prohibit an
immediate reply with the same level of thoroughness, but I look forward to
composing one within a few days' time. Bear with me.


> 1. `MyType.self` is harder to understand for someone who's never seen it
> than `MyType.allValues`. For instance, the expression
> `AccountStatus.allValues[0]` is completely self-explanatory, while
> `AccountStatus.self[0]` is more obscure and would require a trip to the
> documentation. (And since `self` here is a language keyword, not a real
> member, the most obvious route to the documentation is not available.) In
> my opinion, we should not prefer the `MyType.self` syntax.
>
> 2. Even if the community disagrees with me and thinks `MyType.self` is a
> better syntax than `MyType.allValues`, it is not better *enough* to
> outweigh the costs:
>
> • The metatype solution provides no additional functionality; it is merely
> a matter of which syntax we choose to support, and how much effort this
> support requires.
>
> • Conforming the metatype to `Collection` requires a lot of type system
> features we do not currently have. Currently, structural types cannot
> conform to protocols, and metatypes are a structural type. Metatypes also
> cannot have subscripts currently. Your proposed design has a lot of
> prerequisites. That is not in and of itself disqualifying, but it should be
> weighed against it.
>
> • You suggest that we should add bits and pieces of "`Collection`
> functionality" incrementally as engineering resources become available. The
> problem is that the most valuable part of the "`Collection` functionality"
> is conformance to `Collection` or at least `Sequence`, not the existence of
> any particular members of `Collection`, and this is the part that would
> require the most engineering resources.
>
> • A large part of the work we would do before supporting this conformance
> would be disposed of immediately once we could get it. For instance, all of
> the work to support having a metatype instead of a sequence in a `for-in`
> statement would be thrown away as soon as we could conform to `Sequence`.
> So this looks less like slowly building up pieces of the feature until we
> have all of them in place, and more like creating temporary hacks to
> emulate the feature until we have the time to do it right.
>
> • While this feature is not a showstopper, it is a highly desirable
> convenience. The proposal documents the high demand for this feature, so I
> won't elaborate on this point further.
>
> • Therefore, adopting this design would add a lot of engineering
> complexity before we could fully support a highly desirable feature, merely
> to get a syntax that we *might* prefer.
>
> To summarize the summary: The primary advantage of `MyType.self` is that
> it's elegant. To get that elegance, we must trade away getting a
> fully-functional implementation sooner, spending a lot of engineering
> resources (much of which would be wasted in the end), and—most crucially in
> my opinion—clarity at the point of use. It's not worth it.
>
> 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`.
>
>
> Not quite. There are types whose 

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

[Chris Lattner via swift-evolution]

Right.  When I say “statically link” here, I really mean “put the .dylib for 
the library into the app bundle”.  That’s what happens with Swift today.  It 
can be important to share that code between apps and appex’s for example.

-Chris

> On Jan 10, 2018, at 5:02 PM, Wallacy  wrote:
> 
> If I understand this correctly. This is exactly the same argument in favor to 
> maintain the ABI unstable and always bundle the standard library and the 
> runtime with the app.
> 
> Another alternative is, not only, separate the standard library on small 
> pieces, but also dynamic link this specific version of this piece and keep 
> all versions on the SO. (I think the Microsoft did something similar to this)
> 
> On Linux the package manager probably will handle this very well like any 
> other library.
> 
> Even 100 versions in the same SO will not consume enough space to bother 
> anyone.
> 
> 
> Em qua, 10 de jan de 2018 às 17:04, Hooman Mehr via swift-evolution 
> > escreveu:
> Excellent Idea!
> 
> I am all for this. It shouldn’t be too complicated to add a second implicit 
> import and only code that is actually using this stuff will have increased 
> code size.
> 
> > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution 
> > > wrote:
> >
> > 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 

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

[Wallacy via swift-evolution]

If I understand this correctly. This is exactly the same argument in favor
to maintain the ABI unstable and always bundle the standard library and the
runtime with the app.

Another alternative is, not only, separate the standard library on small
pieces, but also dynamic link this specific version of this piece and keep
all versions on the SO. (I think the Microsoft did something similar to
this)

On Linux the package manager probably will handle this very well like any
other library.

Even 100 versions in the same SO will not consume enough space to bother
anyone.


Em qua, 10 de jan de 2018 às 17:04, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> escreveu:

> Excellent Idea!
>
> I am all for this. It shouldn’t be too complicated to add a second
> implicit import and only code that is actually using this stuff will have
> increased code size.
>
> > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > 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
> > 

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

[Nate Cook via swift-evolution]

> On Jan 9, 2018, at 3:07 PM, Jonathan Hull  wrote:
> 
>> 
>> 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.

That should work fine. The savings would depend on whether the algorithms using 
random generators would use the smaller size when necessary.

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

Is it possible for you to share some of this code?

> 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.. 
> Ok, you convinced me on the half-open ranges.
> 
> I still think the best way to handle the 'random() % n' issue is to look for 
> it as a pattern and then just issue a warning/fixit.
> 
>>> - This may sound strange, but I would really like to see Bool handled as a 
>>> default implementation on the generator 

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

[Jordan Rose via swift-evolution]

Remember, the goal here is to support both binary and source compatibility. An 
existing app might be using the enum case that you're trying to remove, but 
there's no chance that an existing app is using an enum case that you're trying 
to add.

Jordan


> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution 
>  wrote:
> 
> If an enum isn’t final; then what’s the difference in deleting as opposed to 
> adding?
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>> 
>> 
>> 
>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>>  a écrit :
>>> 
>>> Two points:
>>> 
>>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>>> distinct from default. 
>>> 
>>> 2. All the discussion is about a framework adding a case, what about when a 
>>> framework deletes a case?
>> 
>> This is a binary breaking change (just like removing an existing function or 
>> method).
>> 
>> 
> ___
> 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]

[Howard Lovatt via swift-evolution]

If an enum isn’t final; then what’s the difference in deleting as opposed to 
adding?

-- Howard. 

> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
> 
> 
> 
>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>  a écrit :
>> 
>> Two points:
>> 
>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>> distinct from default. 
>> 
>> 2. All the discussion is about a framework adding a case, what about when a 
>> framework deletes a case?
> 
> This is a binary breaking change (just like removing an existing function or 
> method).
> 
> 
___
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]

[Mike Kluev via swift-evolution]

on Wed, 10 Jan 2018 07:12:27 + Antoine Cœur 
wrote:

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

this will be logical and consistent. or #default everywhere instead of _

case (#default, #unknown):
case #default:

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

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

[Mike Kluev via swift-evolution]

on Thu, 11 Jan 2018 00:02:18 +0100 Jens Persson  wrote:

If there should be an API to produce a random Double without parameters
> then IMHO it should simply be a uniformly distributed Double in the unit
> range [0, 1). Very useful as a basic building block...


[0..1) sounds reasonable. even if disregard +/- zeroes, infinities, NAN's,
etc., uniform distribution between Double.min ... Double.max makes little
sense.

and it shall be relatively easy to bit cast UInt64 to Double for those who
want to test various double patterns (e.g. for testing).

Mike
___
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 10, 2018, at 2:10 PM, Connor Wakamo  wrote:
>> 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?
> 
> Riley and Saagar answered this down-thread, but to confirm — returning nil 
> would allow some instances of a type to use the “default” playground logging 
> presentation while others use an alternate presentation instead.

Right, this gets back to the question: what is the use case for this?  When 
would a type want to “sometimes” replace the default representation?

It seems to me that a type author either wants to take control of presentation 
or not.  While I’m sure we could imagine some use case for the behavior you’re 
describing, is it big enough to make it worth complicating the API?

> 
> This isn’t handled by `return self` because, unless I’m mistaken, there’s no 
> way to detect that from the caller’s side (e.g. with two `Any` values, I 
> can’t do `self === self.playgroundRepresentation`).

Ok

>> 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 don’t think we can change this to return `Any` instead of `Any?`. I think 
> there are potentially cases where a developer might want to selectively 
> opt-in to this behavior.

Which cases?  How important are they?

> I also don’t think that `Optional` would get a conditional conformance to 
> this. I’m not proposing that any standard library or corelibs types gain 
> conformances to this protocol. Instead, it’s up to a playground logger (such 
> as PlaygroundLogger in swift-xcode-playground-support 
> ) to recognize these 
> types and handle them accordingly. The playground logger would look through 
> the `Optional` so that this would effectively be true, but ideally the log 
> data generated by a logger would indicate that it was wrapped by 
> `Optional.some`.

Why not?  I understand that that is how the old algorithm worked, but it 
contained a lot of special case hacks due to the state of Swift 1 :-).  This is 
a chance to dissolve those away.

To be clear, I would expect that the conformance for optional would be defined 
in the playground module along with this protocol - it wouldn’t be defined in 
the standard library itself.

> 
> One possibility would be to change the API so that it returns an enum. 
> Imagine:
> 
>   enum PlaygroundLoggingBehavior {
>   /// Asks the playground logger to generate the standard logging 
> for `self`.
>   case standard
> 
>   /// Asks the playground logger to generate logging for the 
> given `Any` instead of `self`.
>   case custom(Any)
>   }
> 
>   protocol CustomPlaygroundLoggable {
>   /// Returns the `PlaygroundLoggingBehavior` to use for `self`.
>   var playgroundLoggingBehavior: PlaygroundLoggingBehavior { get }
>   }
> 
> (To Saagar’s point in another email — you could even add a `case none` to 
> PlaygroundLoggingBehavior to inhibit logging of a particular instance.)
> 
> `CustomPlaygroundLoggable` would be a little clunkier to implement than 
> `CustomPlaygroundRepresentable` is, as in the common case folks would have to 
> write `return .custom(…)`. It’s possible that the clarity and additional 
> flexibility this grants outweighs that cost; I’m not sure, and would love 
> feedback on that.

I just don’t understand the usecase for “conditional customizing” at all.  By 
way of example, we don’t have the ability to do that with 
CustomStringConvertible.   What is different about this case?

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

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

[Cheyo Jimenez via swift-evolution]

On Jan 10, 2018, at 8:22 AM, Paul Cantrell via swift-evolution 
 wrote:

>> What is your evaluation of the proposal?
> 
> +1. Yes please. Long overdue.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
> fits my own experience: I’ve wanted this on multiple occasions.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, and in particular, on the name bikeshedding:
> 
> I favor property names with the “all” prefix, whether allValues or allCases. 
> Looking over my own code, I’ve almost always used the word “all” for this 
> when I had to hand-roll it — and either allValues or allCases make reasonable 
> sense in my code when I substitute them.
> 
> Whichever protocol name we choose, the property name should be consistent:
> 
>   ValueEnumerable → allValues
>   CaseEnumerable → allCases

this is good point. I think it would be awesome to also have a compile time 
version named .cases.

.allCases would include unknown cases at runtime.
.cases would only include known at compile time cases. 


> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
> I slightly prefer ValueEnumerable, because it extends to situations where we 
> still want to enumerate a fixed set of possibilities which don’t strictly 
> correspond to enum cases but still have that sort of flavor. For example, one 
> might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
> feature has always worked nicely. Java’s design is slightly different: 
> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
> that name or type choice: (1) Java doesn’t use the term “case” as Swift does, 
> (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
> concrete array type has as opposed to Collection has different implications 
> in Java than it does Swift.
> 
> I _do_ agree  that the proposal should consider constraining the Collection 
> to be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
> leaving that open?
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Medium quick study.
> 
> Cheers, P
> 
> ___
> 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

[Connor Wakamo via swift-evolution]

> On Jan 10, 2018, at 2:34 PM, Saagar Jha  wrote:
> 
> 
> Saagar Jha
> 
>> On Jan 10, 2018, at 14:10, Connor Wakamo > > wrote:
>> 
>>> On Jan 10, 2018, at 12:39 PM, Saagar Jha >> > wrote:
>>> 
>>> Well, in my experience performance issues tend to come not from trying to 
>>> display a single object, but when you have an aggregation of many objects. 
>>> For example, displaying one Int is pretty lightweight, as is an [Int] with 
>>> a handful of elements, but displaying an [Int] with million elements is not 
>>> (this is assuming that collections will run the playgroundRepresentation on 
>>> their individual elements as they do currently). I don’t think the current 
>>> proposal can solve this issue as it’s pitched currently. (For those 
>>> curious, this doesn’t have a good solution today, either: the best 
>>> “solution” I’ve been able to come up with is to move performance-sensitive 
>>> out into a Playground’s Sources folder, which isn’t displayed.)
>> 
>> Yes, this proposal does not affect this case: the playground transform will 
>> still instrument all of the source code in the main source file. This 
>> proposal is merely about deprecating/removing a substandard API for 
>> controlling how values are presented in playgrounds with a better, more 
>> flexible one. (Though see my other reply to Chris where I present an 
>> alternative which could be extended to include support for disabling logging 
>> altogether for an instance.)
>> 
>>> Fundamentally, I don’t think it’s clear what the “default” value is 
>>> supposed to be: we already have three different interpretations of what it 
>>> could do: do literally nothing (i.e. display an empty representation), use 
>>> a superclass’s representation, or use a structural representation based on 
>>> whether the type is an enum, struct, class, etc. I think we need to clear 
>>> up what the default actually means (and if we even need it at all) before 
>>> we can proceed.
>> 
>> This API is a bit wishy-washy as to what the “default” is. That’s somewhat 
>> intentional — the default presentation of an arbitrary Swift value/object is 
>> defined by the IDE, not by an API in Swift. I think my terminology is a bit 
>> confused here, and I’ll try to address that in a revision of the proposal. 
>> Let me try to clarify this a bit:
>> 
>> The fundamental design of playgrounds is that the compiler will insert calls 
>> to a logging function which is effectively required to take an `Any`. So 
>> therefore every instance of every type must be loggable by the playground 
>> logger. The PlaygroundLogger framework in swift-xcode-playground-support 
>>  implements this by 
>> generating either structured log entries using `Mirror` or specialized, 
>> opaque (aka IDERepr) log entries. PlaygroundLogger will generate a 
>> structured log entry for most instances, but for instances of special types 
>> it knows about (e.g. String, Int, NSColor, UIView, etc.) it will generate an 
>> opaque log entry which an IDE can then consume and display as is appropriate.
>> 
>> The CustomPlaygroundRepresentable API I’ve proposed does exactly one thing: 
>> it allows instances of conforming types to provide an optional stand-in to 
>> be used by the playground logger. So PlaygroundLogger would handle the 
>> following cases thusly:
>> 
>>  - If a type conforms to CustomPlaygroundRepresentable and returns a 
>> non-nil value, PlaygroundLogger will generate the appropriate log entry for 
>> the returned value
>>  - If a type conforms to CustomPlaygroundRepresentable and returns nil, 
>> PlaygroundLogger will generate the appropriate log entry for `self`
>>  - If `self` is one of the types (or a subclass of one of the 
>> types) for which PlaygroundLogger generates an opaque entry, 
>> PlaygroundLogger will generate an opaque log entry
>>  - Otherwise, PlaygroundLogger will generate a structured log 
>> entry
> 
> Just wanted to make it totally clear here: is the superclass selected the one 
> that is the closest to the current type, or the one that is the most distant 
> parent? Referring back to the example I had further upthread:
> 
> class FooView: UIView {
>   override var playgroundRepresentation: Any? {
>   return “foo”
>   }
> }
> 
> class BarView: FooView {
>   override var playgroundRepresentation: Any? {
>   return nil
>   }
> }
> 
> Does BarView show up as a UIView, or a FooView? If it’s shown as a FooView, 
> then returning nil is superfluous: you can just not override 
> playgroundRepresentation and it’ll pick up the one from FooView.

Ah, so here’s what it would do: since BarView conforms to 
CustomPlaygroundRepresentable, the playground logger would get the 
playgroundRepresentation. Since playgroundRepresentation returned nil, 

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

[Jean-Daniel via swift-evolution]

> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> Two points:
> 
> 1. I like Chris’s suggestion of #unknown and in particular that it is 
> distinct from default. 
> 
> 2. All the discussion is about a framework adding a case, what about when a 
> framework deletes a case?

This is a binary breaking change (just like removing an existing function or 
method).


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

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

[Jens Persson via swift-evolution]

I agree.

If there should be an API to produce a random Double without parameters
then IMHO it should simply be a uniformly distributed Double in the unit
range [0, 1). Very useful as a basic building block and can be constructed
very fast from a random bitpattern like eg:
extension Double {
init(unitRange v: UInt64) {
self = Double(v >> Double.exponentBitCount) * (.ulpOfOne/2.0)
}
}



On Wed, Jan 10, 2018 at 11:48 PM, Saagar Jha  wrote:

> Which begs the question: why would you want to do something like this?
> Creating a “random” Double from its full range of values is an odd thing to
> do, and the fact that it is non-uniform and has irregularities like
> infinity and signed zeros makes it likely that any such usage is probably
> done in error (the one reason I can think of is if you’re trying to test
> your code with random Doubles, but I’d argue for keeping NaN in that case).
> Generally users are looking for uniform distributions or ones that follow
> some set pattern (e.g. normal, Bernoulli), so this doesn’t seem useful at
> all.
>
> Saagar Jha
>
> On Jan 10, 2018, at 14:39, Jens Persson  wrote:
>
> On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  wrote:
>
>> Not a floating point expert, but are you sure this works? I have a
>> feeling this would lead to a distribution that’s not uniform.
>>
>>
> Yes, it would not be uniform, which is exactly what I meant by the last
> part of: "Assuming you are ok with signed zero and infinities and
> "strange" bias as result of IEEE 754"
>
> Also, I think it's impossible to get a uniform distribution of all non-Nan
> Double values (since they include +- infinity).
>
> /Jens
>
>
>
>> Saagar Jha
>>
>> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> One additional question.  How do you ergonomically get a Double which
>>> doesn’t have a range, but also isn’t NaN?
>>>
>>>
>> Assuming you are ok with signed zero and infinities and "strange" bias as
>> result of IEEE 754:
>>
>> func randomNonNanDouble(using generator: R) ->
>> Double {
>> while true {
>> let rndUInt64 = generator.next()
>> let rndDouble = Double(bitPattern: rndUInt64)
>> if rndDouble != Double.nan { return rndDouble }
>> }
>> }
>>
>> /Jens
>>
>> ___
>> 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-users] Discourse forum rollout next week!

[Howard Lovatt via swift-evolution]

Great news.

Thanks for putting the effort in. 

-- Howard.

> On 10 Jan 2018, at 1:27 pm, Charles Srstka via swift-evolution 
>  wrote:
> 
> :thumbsup:
> 
> Charles
> 
>> On Jan 10, 2018, at 2:22 PM, Nicole Jacque via swift-users 
>>  wrote:
>> 
>> Hi All-
>> 
>> First of all, a big thank you to everyone who has provided feedback on our 
>> prototype Discourse forum. We are ready to move forward with the transition! 
>>  The schedule will be:
>> 
>> 1/17 ~ 6PM Pacific:  We will be putting the mailing lists into suspend mode 
>> in order to do the final export of data for import to the forums
>> 1/19 (exact time TBD) - forums will be up and in production mode.  We’ll 
>> send out one last email at that time to let everyone know.
>> 
>> During the process, I’ll try to keep some status available at 
>> forums.swift.org, but expect about a day and a half of outage time between 
>> the mailing lists going down and the forums being ready.
>> 
>> If you need to contact the Swift infrastructure team during the outage 
>> period the infrastruct...@swift.org email will continue to work.
>> 
>> Thanks!
>> nicole
>> ___
>> swift-users mailing list
>> swift-us...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
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]

[Howard Lovatt via swift-evolution]

Two points:

1. I like Chris’s suggestion of #unknown and in particular that it is distinct 
from default. 

2. All the discussion is about a framework adding a case, what about when a 
framework deletes a case?

-- Howard.

> On 10 Jan 2018, at 1:41 pm, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
> 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!
>>> 
>>> Updated! https://github.com/apple/swift-evolution/pull/777. Also tried to 
>>> clarify some of the points on why I'm leery about #unknown as an arbitrary 
>>> pattern, at least for now.
>> 
>> Hi Jordan,
>> 
>> After a long and hard reading, I will conditionally +1 this:
>> 
>> I agree that this is a problem that “needs" to be solved. (“Needs” is 
>> subjective, because as you correctly point out, there are other languages 
>> that don’t do this and seem to be relatively OK with that)
>> I am ok with the @frozen moniker on enums
>> I am ok with the “#unknown” syntax
>> I am therefore generally ok with the proposed solution
>> 
>> BUT:
>> 
>> I think the application of the warnings is still overly broad. The 
>> frozenness of an enum is only a problem for enums that come from dynamically 
>> linked modules that are external to my built project.
>> 
>> Therefore I’d like to see stuff regarding:
>> 
>> future directions for how we can refine the behavior and tooling around 
>> frozen enums, specifically
>> “statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
>> “version locking"), because statically linking should eliminate frozenness 
>> concerns
>> embedded modules not producing warnings in the future, because embedded 
>> modules only change when the app author decides
>> ruminations on improving tooling for yelling at a developer if they 
>> “unfreeze” an enum in between versions (ie, a reduction of the SemVer 
>> conversation)
>> 
>> Because version locking and knowledge of embedding modules doesn’t currently 
>> exist, we’re forced to deal with the over-applicability of frozenness that 
>> shouldn’t be necessary. Getting those in would go a long way towards getting 
>> this feature scoped down to where it properly belongs in the app development 
>> workflow.
> 
> In other words, the current solution will produce a bunch of false positives, 
> and I’d like to see stuff in the proposal about how those false positives 
> will be addressed.
> 
> Dave
> ___
> 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

[Jordan Rose via swift-evolution]

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

I think this is generally reasonable, and none of the names offend me enough to 
weigh in on that discussion. I do think it's a little weird that @objc enums 
defined in Swift cannot conform to ValueEnumerable, just because imported enums 
won't. (But especially while knee-deep in SE-0192, I think it's correct that 
imported enums won't. The exception could be C enums marked 
`enum_extensibility(closed)`, but I'm not convinced we need that yet.)

The biggest problem I have is unavailable cases. An unavailable case must not 
be instantiated—consider an enum where some cases are only available on iOS and 
not macOS. (I bet we optimize based on this, which makes it all the more 
important to get right.)

I think you should explicitly call out that the derived implementation only 
kicks in when ValueEnumerable is declared on the enum itself, not an extension. 
Or if that's not the case, it should be limited to extensions in the same 
module as the enum. (You could add "unless the enum is '@frozen'", but that's 
not really necessary.)

I don't think this should be implemented with a run-time function; compile-time 
code generation makes more sense to me. But that's an implementation detail; it 
doesn't change the language surface.

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

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

[Saagar Jha via swift-evolution]

Which begs the question: why would you want to do something like this? Creating 
a “random” Double from its full range of values is an odd thing to do, and the 
fact that it is non-uniform and has irregularities like infinity and signed 
zeros makes it likely that any such usage is probably done in error (the one 
reason I can think of is if you’re trying to test your code with random 
Doubles, but I’d argue for keeping NaN in that case). Generally users are 
looking for uniform distributions or ones that follow some set pattern (e.g. 
normal, Bernoulli), so this doesn’t seem useful at all.

Saagar Jha

> On Jan 10, 2018, at 14:39, Jens Persson  wrote:
> 
> On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  > wrote:
> Not a floating point expert, but are you sure this works? I have a feeling 
> this would lead to a distribution that’s not uniform.
> 
> 
> Yes, it would not be uniform, which is exactly what I meant by the last part 
> of: "Assuming you are ok with signed zero and infinities and "strange" bias 
> as result of IEEE 754"
> 
> Also, I think it's impossible to get a uniform distribution of all non-Nan 
> Double values (since they include +- infinity).
> 
> /Jens
> 
>  
> Saagar Jha
> 
>> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution 
>> > wrote:
>> 
>> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> One additional question.  How do you ergonomically get a Double which 
>> doesn’t have a range, but also isn’t NaN?
>> 
>> 
>> Assuming you are ok with signed zero and infinities and "strange" bias as 
>> result of IEEE 754:
>> 
>> func randomNonNanDouble(using generator: R) -> 
>> Double {
>> while true {
>> let rndUInt64 = generator.next()
>> let rndDouble = Double(bitPattern: rndUInt64)
>> if rndDouble != Double.nan { return rndDouble }
>> }
>> }
>> 
>> /Jens
>> 
>> ___
>> 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

[Jens Persson via swift-evolution]

On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  wrote:

> Not a floating point expert, but are you sure this works? I have a feeling
> this would lead to a distribution that’s not uniform.
>
>
Yes, it would not be uniform, which is exactly what I meant by the last
part of: "Assuming you are ok with signed zero and infinities and "strange"
bias as result of IEEE 754"

Also, I think it's impossible to get a uniform distribution of all non-Nan
Double values (since they include +- infinity).

/Jens



> Saagar Jha
>
> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> One additional question.  How do you ergonomically get a Double which
>> doesn’t have a range, but also isn’t NaN?
>>
>>
> Assuming you are ok with signed zero and infinities and "strange" bias as
> result of IEEE 754:
>
> func randomNonNanDouble(using generator: R) ->
> Double {
> while true {
> let rndUInt64 = generator.next()
> let rndDouble = Double(bitPattern: rndUInt64)
> if rndDouble != Double.nan { return rndDouble }
> }
> }
>
> /Jens
>
> ___
> 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 10, 2018, at 14:10, Connor Wakamo  wrote:
> 
>> On Jan 10, 2018, at 12:39 PM, Saagar Jha > > wrote:
>> 
>> Well, in my experience performance issues tend to come not from trying to 
>> display a single object, but when you have an aggregation of many objects. 
>> For example, displaying one Int is pretty lightweight, as is an [Int] with a 
>> handful of elements, but displaying an [Int] with million elements is not 
>> (this is assuming that collections will run the playgroundRepresentation on 
>> their individual elements as they do currently). I don’t think the current 
>> proposal can solve this issue as it’s pitched currently. (For those curious, 
>> this doesn’t have a good solution today, either: the best “solution” I’ve 
>> been able to come up with is to move performance-sensitive out into a 
>> Playground’s Sources folder, which isn’t displayed.)
> 
> Yes, this proposal does not affect this case: the playground transform will 
> still instrument all of the source code in the main source file. This 
> proposal is merely about deprecating/removing a substandard API for 
> controlling how values are presented in playgrounds with a better, more 
> flexible one. (Though see my other reply to Chris where I present an 
> alternative which could be extended to include support for disabling logging 
> altogether for an instance.)
> 
>> Fundamentally, I don’t think it’s clear what the “default” value is supposed 
>> to be: we already have three different interpretations of what it could do: 
>> do literally nothing (i.e. display an empty representation), use a 
>> superclass’s representation, or use a structural representation based on 
>> whether the type is an enum, struct, class, etc. I think we need to clear up 
>> what the default actually means (and if we even need it at all) before we 
>> can proceed.
> 
> This API is a bit wishy-washy as to what the “default” is. That’s somewhat 
> intentional — the default presentation of an arbitrary Swift value/object is 
> defined by the IDE, not by an API in Swift. I think my terminology is a bit 
> confused here, and I’ll try to address that in a revision of the proposal. 
> Let me try to clarify this a bit:
> 
> The fundamental design of playgrounds is that the compiler will insert calls 
> to a logging function which is effectively required to take an `Any`. So 
> therefore every instance of every type must be loggable by the playground 
> logger. The PlaygroundLogger framework in swift-xcode-playground-support 
>  implements this by 
> generating either structured log entries using `Mirror` or specialized, 
> opaque (aka IDERepr) log entries. PlaygroundLogger will generate a structured 
> log entry for most instances, but for instances of special types it knows 
> about (e.g. String, Int, NSColor, UIView, etc.) it will generate an opaque 
> log entry which an IDE can then consume and display as is appropriate.
> 
> The CustomPlaygroundRepresentable API I’ve proposed does exactly one thing: 
> it allows instances of conforming types to provide an optional stand-in to be 
> used by the playground logger. So PlaygroundLogger would handle the following 
> cases thusly:
> 
>   - If a type conforms to CustomPlaygroundRepresentable and returns a 
> non-nil value, PlaygroundLogger will generate the appropriate log entry for 
> the returned value
>   - If a type conforms to CustomPlaygroundRepresentable and returns nil, 
> PlaygroundLogger will generate the appropriate log entry for `self`
>   - If `self` is one of the types (or a subclass of one of the 
> types) for which PlaygroundLogger generates an opaque entry, PlaygroundLogger 
> will generate an opaque log entry
>   - Otherwise, PlaygroundLogger will generate a structured log 
> entry

Just wanted to make it totally clear here: is the superclass selected the one 
that is the closest to the current type, or the one that is the most distant 
parent? Referring back to the example I had further upthread:

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

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

Does BarView show up as a UIView, or a FooView? If it’s shown as a FooView, 
then returning nil is superfluous: you can just not override 
playgroundRepresentation and it’ll pick up the one from FooView.

> 
> This process if potentially recursive (likely up to an implementation-defined 
> limit): if `Foo: CustomPlaygroundRepresentable` and `Bar: 
> CustomPlaygroundRepresentable`, and a `Foo` instance returns an instance of 
> `Bar` from `playgroundRepresentation`, then the playground logger should 
> effectively log `self.playgroundRepresentation.playgroundRepresentation`.
> 
> Connor

Re: [swift-evolution] Incremental ABI stability

[Nevin Brackett-Rozinsky via swift-evolution]

For reference, Chris’s idea can be found here

.

Nevin


On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> I think the best solution is Chris Lattner’s suggestion (responding to
> DictionaryLiteral) to split the shaky stuff into an overlay for Swift
> standard library to maintain compatibility.
>
> On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> 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.
>
>
> 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.
>
>
> This model is unlikely to work well.
>
> Any feature that lacks stable ABI is equivalent to saying "if you use this
> feature in your app then your app will crash or worse on some future OS
> version". That in turn leads to two likely outcomes:
> 1. Apps use the feature. In some future OS version we break them and they
> crash. Users are unhappy.
> 2. Apps use the feature. In some future OS version we decide that we can't
> afford to break them. The "unstable" ABI becomes locked down anyway.
>
> I think we're more likely to simply delete a feature with no replacement
> than to do the above.
>
>
> --
> 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
>
>

On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> I think the best solution is Chris Lattner’s suggestion (responding to
> DictionaryLiteral) to split the shaky stuff into an overlay for Swift
> standard library to maintain compatibility.
>
> On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> 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.
>
>
> 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.
>
>
> This model is unlikely to work 

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

[Saagar Jha via swift-evolution]

Not a floating point expert, but are you sure this works? I have a feeling this 
would lead to a distribution that’s not uniform.

Saagar Jha

> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution 
>  wrote:
> 
> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution 
> > wrote:
> 
> One additional question.  How do you ergonomically get a Double which doesn’t 
> have a range, but also isn’t NaN?
> 
> 
> Assuming you are ok with signed zero and infinities and "strange" bias as 
> result of IEEE 754:
> 
> func randomNonNanDouble(using generator: R) -> 
> Double {
> while true {
> let rndUInt64 = generator.next()
> let rndDouble = Double(bitPattern: rndUInt64)
> if rndDouble != Double.nan { return rndDouble }
> }
> }
> 
> /Jens
> 
> ___
> 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] Incremental ABI stability

[Hooman Mehr via swift-evolution]

I think the best solution is Chris Lattner’s suggestion (responding to 
DictionaryLiteral) to split the shaky stuff into an overlay for Swift standard 
library to maintain compatibility.

> On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution 
>> > wrote:
>> 
>>> 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.
>> 
> 
>> 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.
> 
> This model is unlikely to work well. 
> 
> Any feature that lacks stable ABI is equivalent to saying "if you use this 
> feature in your app then your app will crash or worse on some future OS 
> version". That in turn leads to two likely outcomes:
> 1. Apps use the feature. In some future OS version we break them and they 
> crash. Users are unhappy.
> 2. Apps use the feature. In some future OS version we decide that we can't 
> afford to break them. The "unstable" ABI becomes locked down anyway.
> 
> I think we're more likely to simply delete a feature with no replacement than 
> to do the above.
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Incremental ABI stability

[Greg Parker via swift-evolution]

> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution 
>  wrote:
> 
>> 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.
> 

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

This model is unlikely to work well. 

Any feature that lacks stable ABI is equivalent to saying "if you use this 
feature in your app then your app will crash or worse on some future OS 
version". That in turn leads to two likely outcomes:
1. Apps use the feature. In some future OS version we break them and they 
crash. Users are unhappy.
2. Apps use the feature. In some future OS version we decide that we can't 
afford to break them. The "unstable" ABI becomes locked down anyway.

I think we're more likely to simply delete a feature with no replacement than 
to do the above.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
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 10, 2018, at 12:39 PM, Saagar Jha  wrote:
> 
> Well, in my experience performance issues tend to come not from trying to 
> display a single object, but when you have an aggregation of many objects. 
> For example, displaying one Int is pretty lightweight, as is an [Int] with a 
> handful of elements, but displaying an [Int] with million elements is not 
> (this is assuming that collections will run the playgroundRepresentation on 
> their individual elements as they do currently). I don’t think the current 
> proposal can solve this issue as it’s pitched currently. (For those curious, 
> this doesn’t have a good solution today, either: the best “solution” I’ve 
> been able to come up with is to move performance-sensitive out into a 
> Playground’s Sources folder, which isn’t displayed.)

Yes, this proposal does not affect this case: the playground transform will 
still instrument all of the source code in the main source file. This proposal 
is merely about deprecating/removing a substandard API for controlling how 
values are presented in playgrounds with a better, more flexible one. (Though 
see my other reply to Chris where I present an alternative which could be 
extended to include support for disabling logging altogether for an instance.)

> Fundamentally, I don’t think it’s clear what the “default” value is supposed 
> to be: we already have three different interpretations of what it could do: 
> do literally nothing (i.e. display an empty representation), use a 
> superclass’s representation, or use a structural representation based on 
> whether the type is an enum, struct, class, etc. I think we need to clear up 
> what the default actually means (and if we even need it at all) before we can 
> proceed.

This API is a bit wishy-washy as to what the “default” is. That’s somewhat 
intentional — the default presentation of an arbitrary Swift value/object is 
defined by the IDE, not by an API in Swift. I think my terminology is a bit 
confused here, and I’ll try to address that in a revision of the proposal. Let 
me try to clarify this a bit:

The fundamental design of playgrounds is that the compiler will insert calls to 
a logging function which is effectively required to take an `Any`. So therefore 
every instance of every type must be loggable by the playground logger. The 
PlaygroundLogger framework in swift-xcode-playground-support 
 implements this by 
generating either structured log entries using `Mirror` or specialized, opaque 
(aka IDERepr) log entries. PlaygroundLogger will generate a structured log 
entry for most instances, but for instances of special types it knows about 
(e.g. String, Int, NSColor, UIView, etc.) it will generate an opaque log entry 
which an IDE can then consume and display as is appropriate.

The CustomPlaygroundRepresentable API I’ve proposed does exactly one thing: it 
allows instances of conforming types to provide an optional stand-in to be used 
by the playground logger. So PlaygroundLogger would handle the following cases 
thusly:

- If a type conforms to CustomPlaygroundRepresentable and returns a 
non-nil value, PlaygroundLogger will generate the appropriate log entry for the 
returned value
- If a type conforms to CustomPlaygroundRepresentable and returns nil, 
PlaygroundLogger will generate the appropriate log entry for `self`
- If `self` is one of the types (or a subclass of one of the 
types) for which PlaygroundLogger generates an opaque entry, PlaygroundLogger 
will generate an opaque log entry
- Otherwise, PlaygroundLogger will generate a structured log 
entry

This process if potentially recursive (likely up to an implementation-defined 
limit): if `Foo: CustomPlaygroundRepresentable` and `Bar: 
CustomPlaygroundRepresentable`, and a `Foo` instance returns an instance of 
`Bar` from `playgroundRepresentation`, then the playground logger should 
effectively log `self.playgroundRepresentation.playgroundRepresentation`.

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]

> On Jan 10, 2018, at 1:58 AM, Ian Partridge  wrote:
> 
> On 9 January 2018 at 23:19, Connor Wakamo via swift-evolution
>  wrote:
>> To that end, I am proposing the following:
>> 
>> - 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 }
>> }
> 
> I was always surprised that "Playground" was a word/concept that the
> Standard Library used, as playgrounds are an Xcode feature and iOS app
> which are not part of the Swift open source project.

Agreed — which is why this proposal moves it into the playground-specific 
PlaygroundSupport library instead of leaving it in the standard library.

> I think it might be better if names for these could be found which
> reflect the functionality they provide, in a non "playground" specific
> way. After all, AFAIK it would be possible for non-"playground" uses
> of CustomPlaygroundRepresentable.

As mentioned in another email, I’m open to naming suggestions. That being said, 
in the same way that there’s `CustomStringConvertible` and 
`CustomDebugStringConvertible`, if we come up with a generic name for this, I 
think I’d still probably want a playground-specific version of it that lives in 
the PlaygroundSupport library so that code can customize its behavior to be 
appropriate for different environments/audiences.

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]

> On Jan 9, 2018, at 10:02 PM, Chris Lattner  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?

Riley and Saagar answered this down-thread, but to confirm — returning nil 
would allow some instances of a type to use the “default” playground logging 
presentation while others use an alternate presentation instead.

This isn’t handled by `return self` because, unless I’m mistaken, there’s no 
way to detect that from the caller’s side (e.g. with two `Any` values, I can’t 
do `self === self.playgroundRepresentation`). This would be necessary because 
the intention is that `CustomPlaygroundRepresentable` conformances can chain — 
if I return an object/value which itself conforms to 
`CustomPlaygroundRepresentable`, then the playground logger should follow that 
so that I’m presented the same way as whatever I return would have been. 
(That’s probably not absolutely true, as the PlaygroundLogger library will 
likely have some sort of failsafe to prevent infinite chaining here. But I 
wouldn’t want to rely on such a failsafe mechanism in the design of this API.)

> 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 don’t think we can change this to return `Any` instead of `Any?`. I think 
there are potentially cases where a developer might want to selectively opt-in 
to this behavior.

I also don’t think that `Optional` would get a conditional conformance to this. 
I’m not proposing that any standard library or corelibs types gain conformances 
to this protocol. Instead, it’s up to a playground logger (such as 
PlaygroundLogger in swift-xcode-playground-support 
) to recognize these 
types and handle them accordingly. The playground logger would look through the 
`Optional` so that this would effectively be true, but ideally the log data 
generated by a logger would indicate that it was wrapped by `Optional.some`.

One possibility would be to change the API so that it returns an enum. Imagine:

enum PlaygroundLoggingBehavior {
/// Asks the playground logger to generate the standard logging 
for `self`.
case standard

/// Asks the playground logger to generate logging for the 
given `Any` instead of `self`.
case custom(Any)
}

protocol CustomPlaygroundLoggable {
/// Returns the `PlaygroundLoggingBehavior` to use for `self`.
var playgroundLoggingBehavior: PlaygroundLoggingBehavior { get }
}

(To Saagar’s point in another email — you could even add a `case none` to 
PlaygroundLoggingBehavior to inhibit logging of a particular instance.)

`CustomPlaygroundLoggable` would be a little clunkier to implement than 
`CustomPlaygroundRepresentable` is, as in the common case folks would have to 
write `return .custom(…)`. It’s possible that the clarity and additional 
flexibility this grants outweighs that cost; I’m not sure, and would love 
feedback on that.

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

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

[Jens Persson via swift-evolution]

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

>
> One additional question.  How do you ergonomically get a Double which
> doesn’t have a range, but also isn’t NaN?
>
>
Assuming you are ok with signed zero and infinities and "strange" bias as
result of IEEE 754:

func randomNonNanDouble(using generator: R) ->
Double {
while true {
let rndUInt64 = generator.next()
let rndDouble = Double(bitPattern: rndUInt64)
if rndDouble != Double.nan { return rndDouble }
}
}

/Jens
___
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]

[Dave DeLong via swift-evolution]

> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> 
 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!
>> 
>> Updated! https://github.com/apple/swift-evolution/pull/777 
>> . Also tried to clarify 
>> some of the points on why I'm leery about #unknown as an arbitrary pattern, 
>> at least for now.
> 
> Hi Jordan,
> 
> After a long and hard reading, I will conditionally +1 this:
> 
> I agree that this is a problem that “needs" to be solved. (“Needs” is 
> subjective, because as you correctly point out, there are other languages 
> that don’t do this and seem to be relatively OK with that)
> I am ok with the @frozen moniker on enums
> I am ok with the “#unknown” syntax
> I am therefore generally ok with the proposed solution
> 
> BUT:
> 
> I think the application of the warnings is still overly broad. The frozenness 
> of an enum is only a problem for enums that come from dynamically linked 
> modules that are external to my built project.
> 
> Therefore I’d like to see stuff regarding:
> 
> future directions for how we can refine the behavior and tooling around 
> frozen enums, specifically
> “statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
> “version locking"), because statically linking should eliminate frozenness 
> concerns
> embedded modules not producing warnings in the future, because embedded 
> modules only change when the app author decides
> ruminations on improving tooling for yelling at a developer if they 
> “unfreeze” an enum in between versions (ie, a reduction of the SemVer 
> conversation)
> 
> Because version locking and knowledge of embedding modules doesn’t currently 
> exist, we’re forced to deal with the over-applicability of frozenness that 
> shouldn’t be necessary. Getting those in would go a long way towards getting 
> this feature scoped down to where it properly belongs in the app development 
> workflow.

In other words, the current solution will produce a bunch of false positives, 
and I’d like to see stuff in the proposal about how those false positives will 
be addressed.

Dave___
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

[Paul Cantrell via swift-evolution]

> On Jan 10, 2018, at 2:23 PM, Kevin Nattinger  wrote:
> 
>> [...]
>> 
>> I don’t agree that the Collection should be Int-indexed. Source-order is not 
>> a very strong guarantee IMO, and it wouldn’t be good if people started 
>> writing things like "MyEnum.allValues[3]” to reference a specific case.
> 
> So how do you propose to use allValues with a table view? That's one of the 
> motivating examples, and probably the most common use case. Certainly the 
> most common I've seen.

I assume the mildly inconvenient

static let valuesForTableView = Array(MyEnum.allValues)

…or some such.

> 
>> 
>> If you know the specific case you are looking for, just write it directly. 
>> If you found an interesting case while iterating allValues, remember its 
>> (opaque) index and come back to it later.
>> 
>> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
>> Array, but in general, for generic Collections, I think it implies an awful 
>> lot of knowledge about the Collection’s contents.
>> 
>> - Karl
>> ___
>> 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]

Well, in my experience performance issues tend to come not from trying to 
display a single object, but when you have an aggregation of many objects. For 
example, displaying one Int is pretty lightweight, as is an [Int] with a 
handful of elements, but displaying an [Int] with million elements is not (this 
is assuming that collections will run the playgroundRepresentation on their 
individual elements as they do currently). I don’t think the current proposal 
can solve this issue as it’s pitched currently. (For those curious, this 
doesn’t have a good solution today, either: the best “solution” I’ve been able 
to come up with is to move performance-sensitive out into a Playground’s 
Sources folder, which isn’t displayed.)

Fundamentally, I don’t think it’s clear what the “default” value is supposed to 
be: we already have three different interpretations of what it could do: do 
literally nothing (i.e. display an empty representation), use a superclass’s 
representation, or use a structural representation based on whether the type is 
an enum, struct, class, etc. I think we need to clear up what the default 
actually means (and if we even need it at all) before we can proceed.

Saagar Jha

> On Jan 10, 2018, at 10:02, Chris Lattner  wrote:
> 
>> On Jan 9, 2018, at 11:30 PM, Saagar Jha  wrote:
>>> 
>>> 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?
> 
> If you want a type to display as nothing (e.g. to avoid the perf impact of 
> formatting it) just make the playground representation be an empty string or 
> something.
> 
> -Chris
> 
> 

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Matthew Johnson via swift-evolution]

> On Jan 10, 2018, at 2:19 PM, Rex Fenley  wrote:
> 
> Have you found anyone else to help on this one? I would like to dive in 
> myself but I don't have any experience with the compiler and not sure about 
> the size of the workload here.

Hi Rex, thank you for offering to help!  I have not found anyone else to help 
out on implementation but am still extremely interested in seeing this happen 
and willing to help out by drafting the proposal, etc.

Is anyone who is familiar with it able to give Rex an idea of scope and / or 
willing to help Rex get up to speed?

> 
> On Tue, Dec 5, 2017 at 3:34 PM, Rex Fenley  > wrote:
> Huge +1, I've asked for this in the past too.
> 
> Have you also found this limitation frustrating? 
>   - Yes
> 
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through runtime 
> type checking and throws. Shows up in some network data mapping code I have 
> that generalizes over Core Data and Realm (and other databases). The protocol 
> implementer must specify the subtype for the raw mapping of JSON and base 
> type for the DB reading/writing layer. Could see this showing up whenever 
> there's a separation of concerns between what business logic belongs to the 
> base type and subtypes of a more generalized system. I could potentially see 
> the same issue showing up in code generalizing the mapping of data to UI, 
> like UITableView/UITableViewCell.
> 
> Does anyone have reservations about introducing this capability?
>   - I do not
>> One of the most frequent frustrations I encounter when writing generic code 
>> in Swift is the requirement that supertype constraints be concrete.  When I 
>> mentioned this on Twitter 
>> (https://twitter.com/anandabits/status/929958479598534656 
>> ) Doug Gregor 
>> mentioned that this feature is smaller and mostly straightforward to design 
>> and implement (https://twitter.com/dgregor79/status/929975472779288576 
>> ).
>> 
>> I currently have a PR open to add the high-level description of this feature 
>> found below to the generics manifesto 
>> (https://github.com/apple/swift/pull/13012 
>> ):
>> 
>> Currently, supertype constraints may only be specified using a concrete 
>> class or protocol type.  This prevents us from abstracting over the 
>> supertype.
>> 
>> ```swift
>> protocol P {
>>   associatedtype Base
>>   associatedtype Derived: Base
>> }
>> ```
>> 
>> In the above example `Base` may be any type.  `Derived` may be the same as 
>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>> supported by Swift should be supported in this context including, but not 
>> limited to, classes and subclasses, existentials and conforming concrete 
>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>> `((Derived) -> Void)`, etc.
>> 
>> Generalized supertype constraints would be accepted in all syntactic 
>> locations where generic constraints are accepted.
>> 
>> I would like to see generalized supertype constraints make it into Swift 5 
>> if possible.  I am not an implementer so I will not be able to bring a 
>> proposal forward alone but am interested in collaborating with anyone 
>> interested in working on implementation.
>> 
>> I am also interested in hearing general feedback on this feature from the 
>> community at large.  Have you also found this limitation frustrating?  In 
>> what contexts?  Does anyone have reservations about introducing this 
>> capability?  If so, what are they?
>> 
>> Matthew
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 
___
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]

[Dave DeLong via swift-evolution]

> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>>> 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!
> 
> Updated! https://github.com/apple/swift-evolution/pull/777 
> . Also tried to clarify 
> some of the points on why I'm leery about #unknown as an arbitrary pattern, 
> at least for now.

Hi Jordan,

After a long and hard reading, I will conditionally +1 this:

I agree that this is a problem that “needs" to be solved. (“Needs” is 
subjective, because as you correctly point out, there are other languages that 
don’t do this and seem to be relatively OK with that)
I am ok with the @frozen moniker on enums
I am ok with the “#unknown” syntax
I am therefore generally ok with the proposed solution

BUT:

I think the application of the warnings is still overly broad. The frozenness 
of an enum is only a problem for enums that come from dynamically linked 
modules that are external to my built project.

Therefore I’d like to see stuff regarding:

future directions for how we can refine the behavior and tooling around frozen 
enums, specifically
“statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
“version locking"), because statically linking should eliminate frozenness 
concerns
embedded modules not producing warnings in the future, because embedded modules 
only change when the app author decides
ruminations on improving tooling for yelling at a developer if they “unfreeze” 
an enum in between versions (ie, a reduction of the SemVer conversation)

Because version locking and knowledge of embedding modules doesn’t currently 
exist, we’re forced to deal with the over-applicability of frozenness that 
shouldn’t be necessary. Getting those in would go a long way towards getting 
this feature scoped down to where it properly belongs in the app development 
workflow.

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

Re: [swift-evolution] [swift-users] Discourse forum rollout next week!

[Charles Srstka via swift-evolution]

:thumbsup:

Charles

> On Jan 10, 2018, at 2:22 PM, Nicole Jacque via swift-users 
>  wrote:
> 
> Hi All-
> 
> First of all, a big thank you to everyone who has provided feedback on our 
> prototype Discourse forum. We are ready to move forward with the transition!  
> The schedule will be:
> 
> 1/17 ~ 6PM Pacific:  We will be putting the mailing lists into suspend mode 
> in order to do the final export of data for import to the forums
> 1/19 (exact time TBD) - forums will be up and in production mode.  We’ll send 
> out one last email at that time to let everyone know.
> 
> During the process, I’ll try to keep some status available at 
> forums.swift.org, but expect about a day and a half of outage time between 
> the mailing lists going down and the forums being ready.
> 
> If you need to contact the Swift infrastructure team during the outage period 
> the infrastruct...@swift.org email will continue to work.
> 
> Thanks!
> nicole
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

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

[Kevin Nattinger via swift-evolution]

> [...]
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.

So how do you propose to use allValues with a table view? That's one of the 
motivating examples, and probably the most common use case. Certainly the most 
common I've seen.

> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl
> ___
> 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] Discourse forum rollout next week!

[Nicole Jacque via swift-evolution]

Hi All-

First of all, a big thank you to everyone who has provided feedback on our 
prototype Discourse forum. We are ready to move forward with the transition!  
The schedule will be:

1/17 ~ 6PM Pacific:  We will be putting the mailing lists into suspend mode in 
order to do the final export of data for import to the forums
1/19 (exact time TBD) - forums will be up and in production mode.  We’ll send 
out one last email at that time to let everyone know.

During the process, I’ll try to keep some status available at forums.swift.org, 
but expect about a day and a half of outage time between the mailing lists 
going down and the forums being ready.

If you need to contact the Swift infrastructure team during the outage period 
the infrastruct...@swift.org email will continue to work.

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Rex Fenley via swift-evolution]

Have you found anyone else to help on this one? I would like to dive in
myself but I don't have any experience with the compiler and not sure about
the size of the workload here.

On Tue, Dec 5, 2017 at 3:34 PM, Rex Fenley  wrote:

> Huge +1, I've asked for this in the past too.
>
> Have you also found this limitation frustrating?
>   - Yes
>
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through
> runtime type checking and throws. Shows up in some network data mapping
> code I have that generalizes over Core Data and Realm (and other
> databases). The protocol implementer must specify the subtype for the raw
> mapping of JSON and base type for the DB reading/writing layer. Could see
> this showing up whenever there's a separation of concerns between what
> business logic belongs to the base type and subtypes of a more generalized
> system. I could potentially see the same issue showing up in code
> generalizing the mapping of data to UI, like UITableView/UITableViewCell.
>
> Does anyone have reservations about introducing this capability?
>   - I do not
>
> One of the most frequent frustrations I encounter when writing generic
> code in Swift is the requirement that supertype constraints be concrete.
> When I mentioned this on Twitter (https://twitter.com/anandabit
> s/status/929958479598534656) Doug Gregor mentioned that this feature is
> smaller and mostly straightforward to design and implement (
> https://twitter.com/dgregor79/status/929975472779288576).
>
> I currently have a PR open to add the high-level description of this
> feature found below to the generics manifesto (
> https://github.com/apple/swift/pull/13012):
>
> Currently, supertype constraints may only be specified using a concrete
> class or protocol type.  This prevents us from abstracting over the
> supertype.
>
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
>
> In the above example `Base` may be any type.  `Derived` may be the same as
> `Base` or may be _any_ subtype of `Base`.  All subtype relationships
> supported by Swift should be supported in this context including, but not
> limited to, classes and subclasses, existentials and conforming concrete
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and
> `((Derived) -> Void)`, etc.
>
> Generalized supertype constraints would be accepted in all syntactic
> locations where generic constraints are accepted.
>
> I would like to see generalized supertype constraints make it into Swift 5
> if possible.  I am not an implementer so I will not be able to bring a
> proposal forward alone but am interested in collaborating with anyone
> interested in working on implementation.
>
> I am also interested in hearing general feedback on this feature from the
> community at large.  Have you also found this limitation frustrating?  In
> what contexts?  Does anyone have reservations about introducing this
> capability?  If so, what are they?
>
> Matthew
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
>
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com  |  BLOG   |
>  FOLLOW US   |  LIKE US
> 
>



-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

___
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 10, 2018, at 10:10 AM, Riley Testut  wrote:
> 
> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 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?
> 
> I assumed it could be used if a type’s playground representation was 
> variable. For instance:
> 
> enum MyUnion
> {
> case string(String)
> case image(UIImage)
> case none
> }
> 
> In its implementation of CustomPlaygroundRepresentable, it could return a 
> string if case string, an image if case image, or return nil if case none to 
> just do whatever is the default for enum values. 
> 
> Admittedly the above is a very contrived example, but I do think it is 
> important to allow types to opt-out.

You should just be able to return ‘self' in that case?

-Chris


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

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

[Matthew Johnson via swift-evolution]

> What is your evaluation of the proposal?

+1.  I have written plenty of enums with the `allValues` property.  It will be 
nice to have this synthesized.

I do think a small clarification or revision is warranted, however.  I would 
like to see a rationale stated for choosing the `Collection` requirement rather 
than `Sequence` or `RandomAccessCollection`.  The `Sequence` alternative has 
been discussed in some depth on the list and this discussion is not represented 
in the alternatives section.

I bring up `RandomAccessCollection` as an alternative worth discussing because 
I strongly believe the proposal should require the compiler synthesized 
`ValueCollection` types to also conform to `RandomAccessCollection` and further 
have `Int` indices.  One of the leading motivating use cases for this proposal 
is in implementing data sources which requires both `Int` indices and also 
carries an expectation of a constant time subscript operation.  

Placing a stronger requirement on the compiler-synthesized implementation than 
we do on manual conformances is somewhat subtle so we should at least consider 
whether such requirements are acceptable for all conformances or not and 
address that in the proposal.  I don’t know of any use cases for a manual 
conformance where meeting the stricter requirements would be problematic.  On 
the other hand, requiring an `Int` index in particular seems like it is 
probably too strict.  

I support the proposal regardless of the decision but believe additional 
discussion and documentation of the alternative constraints would be healthy.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Absolutely.  This is a very common source of boilerplate that is prone to break 
as code changes.

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

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

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
In-depth study and participation in prior threads.___
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 10, 2018, at 12:04, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner  > wrote:
> 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.
> 
> I was just curious since a RawRepresentable structs ( and OptionSet ) are 
> very similar to non exhaustive enums in that they would require handling 
> unknown cases. Currently RawRepresentable is required to use a default even 
> if all cases are accounted for. 
> 
> struct Directions: OptionSet {
> let rawValue: UInt8
> static let up= Directions(rawValue: 1 << 0)
> }
> 
> let myDir = Directions.up
> 
> switch myDir
> {
> case .up : print("matched")
> default: print("default required") 
> }

Since an option set has 2^N possible values, not just N, we don't expect anyone 
to be switching over them! And it wouldn't be correct to try to do so 
exhaustively anyway.

Jordan

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

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

Updated! https://github.com/apple/swift-evolution/pull/777. Also tried to 
clarify some of the points on why I'm leery about #unknown as an arbitrary 
pattern, at least for now.

Jordan

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

[Jose Cheyo Jimenez via swift-evolution]

On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner  wrote:

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

I was just curious since a RawRepresentable structs ( and OptionSet ) are
very similar to non exhaustive enums in that they would require handling
unknown cases. Currently RawRepresentable is required to use a default even
if all cases are accounted for.

struct Directions: OptionSet {
let rawValue: UInt8
static let up= Directions(rawValue: 1 << 0)
}

let myDir = Directions.up

switch myDir
{
case .up : print("matched")
default: print("default required")
}



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

[swift-evolution] String update

[Michael Ilseman via swift-evolution]

Hello, I just sent an email to swift-dev titled "State of String: ABI, 
Performance, Ergonomics, and You!” at 
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html, 
whose gist can be found at 
https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f. I posted to 
swift-dev as much of the content is from an implementation perspective, but it 
also addresses many areas of potential evolution. Please refer to that email 
for details; here’s the recap from it:

### Recap: Potential Additions for Swift 5

* Some form of unmanaged or unsafe Strings, and corresponding APIs
* Exposing performance flags, and some way to request a scan to populate them
* API gaps
* Character and UnicodeScalar properties, such as isNewline
* Generalizing, and optimizing, String interpolation
* Regex literals, Regex type, and generalized pattern match destructuring
* Substitution APIs, in conjunction with Regexes.

___
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

[Paul Cantrell via swift-evolution]

> On Jan 10, 2018, at 12:44 PM, Karl Wagner  wrote:
> 
> 
> 
>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> +1. Yes please. Long overdue.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
>> fits my own experience: I’ve wanted this on multiple occasions.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, and in particular, on the name bikeshedding:
>> 
>> I favor property names with the “all” prefix, whether allValues or allCases. 
>> Looking over my own code, I’ve almost always used the word “all” for this 
>> when I had to hand-roll it — and either allValues or allCases make 
>> reasonable sense in my code when I substitute them.
>> 
>> Whichever protocol name we choose, the property name should be consistent:
>> 
>>  ValueEnumerable → allValues
>>  CaseEnumerable → allCases
>> 
>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
>> I slightly prefer ValueEnumerable, because it extends to situations where we 
>> still want to enumerate a fixed set of possibilities which don’t strictly 
>> correspond to enum cases but still have that sort of flavor. For example, 
>> one might want:
>> 
>> enum SideOfBody
>>   {
>>   case left
>>   case right
>>   }
>> 
>> enum Limb: ValueEnumerable
>>   {
>>   case arm(SideOfBody)
>>   case leg(SideOfBody)
>> 
>>   static let allValues =
>> [
>> arm(.left),
>> arm(.right),
>> leg(.left),
>> leg(.right)
>> ]
>>   }
>> 
>> To my eyes, this code reads better than it would with CaseEnumerable / 
>> allCases.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>> feature has always worked nicely. Java’s design is slightly different: 
>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>> using a concrete array type has as opposed to Collection has different 
>> implications in Java than it does Swift.
>> 
>> I _do_ agree  that the proposal should consider constraining the Collection 
>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>> for leaving that open?
> 
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.

You do make a good point about the hidden brittleness of MyEnum.allValues[3].

Direct indexing of collections using arbitrary hard-coded int indexes is a way 
to introduce brittleness in many other existing contexts, and I’d say 
developers already know that it has a bad smell (or are making other far larger 
mistakes as well). However, using int indices for serialization seems a pitfall 
that would catch many people. Is there a way to make transient use of ints 
convenient (as in the proposal’s table view example) but persistent int values 
inconvenient? No.

There are clearly enums where source ordering is intentional and significant, 
and others where the enum is inherently unordered. An alternative would be two 
protocols, one where allValues is a Set and one where it is an Array, or 
something along those lines. That feels like overkill to me, however.

Perhaps the proposal as it stands is the best compromise: everything is 
ordered, even if the ordering is not stable between versions, but int indexing 
is inconvenient enough to turn away the more careless among us.

Cheers, P

> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl

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

Excellent Idea!

I am all for this. It shouldn’t be too complicated to add a second implicit 
import and only code that is actually using this stuff will have increased code 
size.

> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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

___
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

[Dave DeLong via swift-evolution]

Yes please to Int indexes.

One of the things I despise most about the Collection protocol is how it allows 
for arbitrary index types. That, IMO, was an awful, awful mistake.

Dave

> On Jan 10, 2018, at 11:45 AM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> Simple is better. Int indexes, please. 
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk  <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> * http://agilesolutionspace.blogspot.com/ 
> 
> 
> On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>>> > wrote:
>>> 
 What is your evaluation of the proposal?
>>> 
>>> +1. Yes please. Long overdue.
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> 
>>> It’s a long-standing sore thumb. The proposal’s evidence of community 
>>> demand fits my own experience: I’ve wanted this on multiple occasions.
>>> 
 Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes, and in particular, on the name bikeshedding:
>>> 
>>> I favor property names with the “all” prefix, whether allValues or 
>>> allCases. Looking over my own code, I’ve almost always used the word “all” 
>>> for this when I had to hand-roll it — and either allValues or allCases make 
>>> reasonable sense in my code when I substitute them.
>>> 
>>> Whichever protocol name we choose, the property name should be consistent:
>>> 
>>> ValueEnumerable → allValues
>>> CaseEnumerable → allCases
>>> 
>>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra 
>>> Chris, I slightly prefer ValueEnumerable, because it extends to situations 
>>> where we still want to enumerate a fixed set of possibilities which don’t 
>>> strictly correspond to enum cases but still have that sort of flavor. For 
>>> example, one might want:
>>> 
>>> enum SideOfBody
>>>   {
>>>   case left
>>>   case right
>>>   }
>>> 
>>> enum Limb: ValueEnumerable
>>>   {
>>>   case arm(SideOfBody)
>>>   case leg(SideOfBody)
>>> 
>>>   static let allValues =
>>> [
>>> arm(.left),
>>> arm(.right),
>>> leg(.left),
>>> leg(.right)
>>> ]
>>>   }
>>> 
>>> To my eyes, this code reads better than it would with CaseEnumerable / 
>>> allCases.
>>> 
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
>>> 
>>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>>> feature has always worked nicely. Java’s design is slightly different: 
>>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>>> using a concrete array type has as opposed to Collection has different 
>>> implications in Java than it does Swift.
>>> 
>>> I _do_ agree  that the proposal should consider constraining the Collection 
>>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>>> for leaving that open?
>>> 
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
>>> 
>>> Medium quick study.
>>> 
>>> Cheers, P
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> I don’t agree that the Collection should be Int-indexed. Source-order is not 
>> a very strong guarantee IMO, and it wouldn’t be good if people started 
>> writing things like "MyEnum.allValues[3]” to reference a specific case.
>> 
>> If you know the specific case you are looking for, just write it directly. 
>> If you found an interesting case while iterating allValues, remember its 
>> (opaque) index and come back to it later.
>> 
>> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
>> Array, but in general, for generic Collections, I think it implies an awful 
>> lot of knowledge about the Collection’s contents.
>> 
>> - Karl
>> ___
>> 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

[C. Keith Ray via swift-evolution]

Simple is better. Int indexes, please. 

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
> 
>>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> +1. Yes please. Long overdue.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
>> fits my own experience: I’ve wanted this on multiple occasions.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, and in particular, on the name bikeshedding:
>> 
>> I favor property names with the “all” prefix, whether allValues or allCases. 
>> Looking over my own code, I’ve almost always used the word “all” for this 
>> when I had to hand-roll it — and either allValues or allCases make 
>> reasonable sense in my code when I substitute them.
>> 
>> Whichever protocol name we choose, the property name should be consistent:
>> 
>>  ValueEnumerable → allValues
>>  CaseEnumerable → allCases
>> 
>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
>> I slightly prefer ValueEnumerable, because it extends to situations where we 
>> still want to enumerate a fixed set of possibilities which don’t strictly 
>> correspond to enum cases but still have that sort of flavor. For example, 
>> one might want:
>> 
>> enum SideOfBody
>>   {
>>   case left
>>   case right
>>   }
>> 
>> enum Limb: ValueEnumerable
>>   {
>>   case arm(SideOfBody)
>>   case leg(SideOfBody)
>> 
>>   static let allValues =
>> [
>> arm(.left),
>> arm(.right),
>> leg(.left),
>> leg(.right)
>> ]
>>   }
>> 
>> To my eyes, this code reads better than it would with CaseEnumerable / 
>> allCases.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>> feature has always worked nicely. Java’s design is slightly different: 
>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>> using a concrete array type has as opposed to Collection has different 
>> implications in Java than it does Swift.
>> 
>> I _do_ agree  that the proposal should consider constraining the Collection 
>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>> for leaving that open?
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Medium quick study.
>> 
>> Cheers, P
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.
> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl
> ___
> 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

[Karl Wagner via swift-evolution]

> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> 
> +1. Yes please. Long overdue.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
> fits my own experience: I’ve wanted this on multiple occasions.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, and in particular, on the name bikeshedding:
> 
> I favor property names with the “all” prefix, whether allValues or allCases. 
> Looking over my own code, I’ve almost always used the word “all” for this 
> when I had to hand-roll it — and either allValues or allCases make reasonable 
> sense in my code when I substitute them.
> 
> Whichever protocol name we choose, the property name should be consistent:
> 
>   ValueEnumerable → allValues
>   CaseEnumerable → allCases
> 
> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
> I slightly prefer ValueEnumerable, because it extends to situations where we 
> still want to enumerate a fixed set of possibilities which don’t strictly 
> correspond to enum cases but still have that sort of flavor. For example, one 
> might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
> feature has always worked nicely. Java’s design is slightly different: 
> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
> that name or type choice: (1) Java doesn’t use the term “case” as Swift does, 
> (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
> concrete array type has as opposed to Collection has different implications 
> in Java than it does Swift.
> 
> I _do_ agree  that the proposal should consider constraining the Collection 
> to be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
> leaving that open?
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Medium quick study.
> 
> Cheers, P
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


I don’t agree that the Collection should be Int-indexed. Source-order is not a 
very strong guarantee IMO, and it wouldn’t be good if people started writing 
things like "MyEnum.allValues[3]” to reference a specific case.

If you know the specific case you are looking for, just write it directly. If 
you found an interesting case while iterating allValues, remember its (opaque) 
index and come back to it later.

I’m not a fan of Int-indexes in general. It’s practical to allow it for Array, 
but in general, for generic Collections, I think it implies an awful lot of 
knowledge about the Collection’s contents.

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

[Riley Testut via swift-evolution]

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution 
>  wrote:


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

I assumed it could be used if a type’s playground representation was variable. 
For instance:

enum MyUnion
{
case string(String)
case image(UIImage)
case none
}

In its implementation of CustomPlaygroundRepresentable, it could return a 
string if case string, an image if case image, or return nil if case none to 
just do whatever is the default for enum values. 

Admittedly the above is a very contrived example, but I do think it is 
important to allow types to opt-out.

> On Jan 9, 2018, at 10:02 PM, 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.  :-)
> 
> 
>> /// 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]

[Jordan Rose via swift-evolution]

> On Jan 9, 2018, at 22:17, Chris Lattner  wrote:
> 
> 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.

Notify, yes. Error, no. It's a design goal that adding a new case does not 
break source compatibility in addition to not breaking binary compatibility 
(because people don't like editing their dependencies) and therefore the 
behavior has to be defined when they recompile with no changes.

(This should also cover why it's more difficult to implement both diagnostics 
and SILGen for it.)

Jordan


> 
>> - 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] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 9, 2018, at 21:39, Brent Royal-Gordon  wrote:
> 
> 
> 
>> 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
>   }
>   …

Yes, you can write that, but why would you do it? What are you going to do 
below now that you know 'someEnum' is a known value but the compiler doesn't?

(Also, it doesn't play well with recompiling…)


> 
>> 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] [Proposal] Revamp the playground quicklook APIs

[Chris Lattner via swift-evolution]

> On Jan 9, 2018, at 11:30 PM, Saagar Jha  wrote:
>> 
>> 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?

If you want a type to display as nothing (e.g. to avoid the perf impact of 
formatting it) just make the playground representation be an empty string or 
something.

-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 10, 2018, at 1:52 AM, Ian Partridge  wrote:
> 
> On 10 January 2018 at 06:29, Chris Lattner via swift-evolution
>  wrote:
>> 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).
> 
> It's true that they are not widely used, but they are in use.  For
> example IBM's SQL abstraction library called "Kuery" depends on
> Mirror.
> 
> https://github.com/IBM-Swift/Swift-Kuery/blob/1d05ad6435cf7fa5feebba663bd3f765c72634e1/Sources/SwiftKuery/Table.swift#L42
>  
> 

Right.  That’s exactly the reason we don’t want to remove them outright (that 
would be a major source breakage).  Moving them to a separate module solves 
this concern and allows a better implementation to come in and be standardized 
later.

-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

[Paul Cantrell via swift-evolution]

> What is your evaluation of the proposal?

+1. Yes please. Long overdue.

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

It’s a long-standing sore thumb. The proposal’s evidence of community demand 
fits my own experience: I’ve wanted this on multiple occasions.

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

Yes, and in particular, on the name bikeshedding:

I favor property names with the “all” prefix, whether allValues or allCases. 
Looking over my own code, I’ve almost always used the word “all” for this when 
I had to hand-roll it — and either allValues or allCases make reasonable sense 
in my code when I substitute them.

Whichever protocol name we choose, the property name should be consistent:

ValueEnumerable → allValues
CaseEnumerable → allCases

Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, I 
slightly prefer ValueEnumerable, because it extends to situations where we 
still want to enumerate a fixed set of possibilities which don’t strictly 
correspond to enum cases but still have that sort of flavor. For example, one 
might want:

enum SideOfBody
  {
  case left
  case right
  }

enum Limb: ValueEnumerable
  {
  case arm(SideOfBody)
  case leg(SideOfBody)

  static let allValues =
[
arm(.left),
arm(.right),
leg(.left),
leg(.right)
]
  }

To my eyes, this code reads better than it would with CaseEnumerable / allCases.

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

Java’s enums had this from the beginning, and Josh Bloch’s design for that 
feature has always worked nicely. Java’s design is slightly different: 
`Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either that 
name or type choice: (1) Java doesn’t use the term “case” as Swift does, (2) 
the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
concrete array type has as opposed to Collection has different implications in 
Java than it does Swift.

I _do_ agree  that the proposal should consider constraining the Collection to 
be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
leaving that open?

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

Medium quick study.

Cheers, P

___
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

[Brent Royal-Gordon via swift-evolution]

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 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.

I can't speak for the other co-authors, but for my part, this was an oversight 
and I apologize for it. I think we should have discussed your `MyType.self` 
alternative.

I won't rehash the entire discussion in previous threads, but to summarize my 
objections:

1. `MyType.self` is harder to understand for someone who's never seen 
it than `MyType.allValues`. For instance, the expression 
`AccountStatus.allValues[0]` is completely self-explanatory, while 
`AccountStatus.self[0]` is more obscure and would require a trip to the 
documentation. (And since `self` here is a language keyword, not a real member, 
the most obvious route to the documentation is not available.) In my opinion, 
we should not prefer the `MyType.self` syntax.

2. Even if the community disagrees with me and thinks `MyType.self` is 
a better syntax than `MyType.allValues`, it is not better *enough* to outweigh 
the costs:

• The metatype solution provides no additional functionality; 
it is merely a matter of which syntax we choose to support, and how much effort 
this support requires.

• Conforming the metatype to `Collection` requires a lot of 
type system features we do not currently have. Currently, structural types 
cannot conform to protocols, and metatypes are a structural type. Metatypes 
also cannot have subscripts currently. Your proposed design has a lot of 
prerequisites. That is not in and of itself disqualifying, but it should be 
weighed against it.

• You suggest that we should add bits and pieces of 
"`Collection` functionality" incrementally as engineering resources become 
available. The problem is that the most valuable part of the "`Collection` 
functionality" is conformance to `Collection` or at least `Sequence`, not the 
existence of any particular members of `Collection`, and this is the part that 
would require the most engineering resources.

• A large part of the work we would do before supporting this 
conformance would be disposed of immediately once we could get it. For 
instance, all of the work to support having a metatype instead of a sequence in 
a `for-in` statement would be thrown away as soon as we could conform to 
`Sequence`. So this looks less like slowly building up pieces of the feature 
until we have all of them in place, and more like creating temporary hacks to 
emulate the feature until we have the time to do it right.

• While this feature is not a showstopper, it is a highly 
desirable convenience. The proposal documents the high demand for this feature, 
so I won't elaborate on this point further.

• Therefore, adopting this design would add a lot of 
engineering complexity before we could fully support a highly desirable 
feature, merely to get a syntax that we *might* prefer.

To summarize the summary: The primary advantage of `MyType.self` is that it's 
elegant. To get that elegance, we must trade away getting a fully-functional 
implementation sooner, spending a lot of engineering resources (much of which 
would be wasted in the end), and—most crucially in my opinion—clarity at the 
point of use. It's not worth it.

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

Not quite. There are types whose valid values are unknowable; for instance, a 
type representing "the ID of a record on the server" cannot know which IDs 
actually exist on the server, merely which ones *could* exist, and so an 
implementation of `allValues` would 

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

[Ian Partridge via swift-evolution]

On 9 January 2018 at 23:19, Connor Wakamo via swift-evolution
 wrote:
> To that end, I am proposing the following:
>
> - 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 }
> }

I was always surprised that "Playground" was a word/concept that the
Standard Library used, as playgrounds are an Xcode feature and iOS app
which are not part of the Swift open source project.

I think it might be better if names for these could be found which
reflect the functionality they provide, in a non "playground" specific
way. After all, AFAIK it would be possible for non-"playground" uses
of CustomPlaygroundRepresentable.

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

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

[Ian Partridge via swift-evolution]

On 10 January 2018 at 06:29, Chris Lattner via swift-evolution
 wrote:
> 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).

It's true that they are not widely used, but they are in use.  For
example IBM's SQL abstraction library called "Kuery" depends on
Mirror.

https://github.com/IBM-Swift/Swift-Kuery/blob/1d05ad6435cf7fa5feebba663bd3f765c72634e1/Sources/SwiftKuery/Table.swift#L42

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