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

[Antoine Cœur via swift-evolution]

I read:

Ma.allValues.count   // returns 8

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

Ma.lazy.allValues.count   // returns 8

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

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

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

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

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

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

[Antoine Cœur via swift-evolution]

And what about, as an alternative:

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

Then it clearly goes the "pattern matching" way.


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

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

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

[Antoine Cœur via swift-evolution]

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

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

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


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

>
>
> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The mega-thread about SE-0192 is a bit large, and I’d like to talk about
> one specific point.  In the review conversation, there has been significant
> objection to the idea of requiring a ‘default’ for switches over enums that
> are non-exhaustive.
>
> This whole discussion is happening because the ABI stability work is
> introducing a new concept to enums - invisible members/inhabitants (and
> making them reasonably prominent).  A closely related feature is that may
> come up in the future is "private cases”.  Private cases are orthogonal to
> API evolution and may even occur on one that is defined to be exhaustive.
>
> Private cases and non-exhaustive enums affect the enum in the same way:
> they say that the enum can have values that a client does not know about.
> Swift requires switches to process *all* of the dynamically possible
> values, which is why the original proposal started out with the simplest
> possible solution: just require ‘default' when processing the cases.
>
>
> *The problems with “unknown case:”*
>
> The popular solution to this probably is currently being pitched as a
> change to the proposal (https://github.com/apple/swift-evolution/pull/777)
> which introduces a new concept “unknown case” as a near-alias for ‘default’:
>
> https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case
>
> In short, I think this is the wrong way to solve the problem.  I have
> several concerns with this:
>
> 1) Unlike in C, switch is Swift is a general pattern matching facility -
> not a way of processing integers.  It supports recursive patterns and
> values, and enums are not necessarily at the top-level of the pattern.
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a
> document from early evolution of Swift but contains a good general
> introduction to this.
>
> 2) Swift also has other facilities for pattern matching, including ‘if
> case’.  Making switch inconsistent with them is not great.
>
> 3) As pitched, “unknown case” will match *known* cases too, which is (in
> my opinion :-) oxymoronic.
>
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a
> modifier on case) because case *requires* a pattern.  A better spelling
> would be “unknown default:” which is closer to the semantic provided anyway.
>
> 5) It is entirely reasonable (though rare in practice) to want to handle
> default and unknown cases in the same switch.
>
>
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the
> side of switch/case, not something that fits in naturally with the rest of
> Swift.
>
>
> *Alternative proposal:*
>
> Instead of introducing a new modifier on case/switch, lets just introduce
> a new pattern matching operator that *matches unknown cases*, called
> “#unknown” or “.#unknown” or something (I’m not wed to the syntax, better
> suggestions welcome :).
>
> In the simple case most people are talking about, instead of writing
> “unknown case:” you’d write “case #unknown:” which isn’t much different.
> The nice thing about this is that #unknown slots directly into our pattern
> matching system.  Here is a weird example:
>
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
>
> Furthermore, if you have a switch that enumerates all of the known cases
> and use #unknown, then it falls out of the model that new cases (e.g. due
> to an SDK upgrade or an updated source package) produces the existing build
> error.  As with the original proposal, you can always choose to use
> “default:” instead of “case #unknown:” if you don’t like that behavior.
>
> Of course, if you have an exhaustive enum (e.g. one defined in your own
> module or explicitly marked as such) then #unknown matches nothing, so we
> should warn about it being pointless.
>
>
> This addresses my concerns above:
>
> 1) This fits into patterns in recursive positions, and slots directly into
> the existing grammar for patterns.  It would be a very simple extension to
> the compiler instead of a special case added to switch/case.
>

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Antoine Cœur via swift-evolution]

>
> * What is your evaluation of the proposal?
>
-1, we are introducing confusion between WHAT is returned and IF it returns


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
the assumption that the attribute was superfluous was wrong, for clarity
reasons. So there is no significant problem addressed


> * Does this proposal fit well with the feel and direction of Swift?
>
This proposal feels like someone wants to remove '@' from attributes: this
causes confusion. I may have defined a class with name NoReturn for a
different use.

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

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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Antoine Cœur via swift-evolution]

Forgive me for creating a new thread, I don't know how to reply to an
archived discussion (I just registered to the mailing-list).


> On *Wed Jun 15 15:09:52 CDT 2016, **Matthew Johnson* matthew at
anandabits.com

wrote:

> There are two reasonable options here:

>

> 1. Allow both `private` and `fileprivate` at file scope despite the fact
that they have the same meaning.  This is more consistent in the sense that
we are not introducing a special case that arbitrarily prohibits an
otherwise valid access modifier.  It also means that nothing needs to
change for top level `private` declarations in existing code.

>

> 2. Prohibit `private` at file scope.  Given that it appears as if the
behavior of `private` at file scope may not be intuitive and is equivalent
to `fileprivate` it might be reasonable to just disallow it.  This would
result in more consistent *code* (even if there needs to be a special case
in the language).

>

> I don’t have a strong opinion on which option we choose.  But I do feel
strongly that the semantics of `private` need to properly respect the scope
in which the keyword is written and into which the associated declaration
is introduced (rather than the scope *inside* the declaration it is
attached to).

The way we are defining those makes `fileprivate` closer to `internal` than
to `private`:

* `fileprivate` and `internal` have a predefined scope level (the file, the
module)

* `private` has a scope level depending on where it is declared

It would be more consistent to:

a) either rename `fileprivate` to `fileinternal`

b) either scoping `internal` keyword explicitly with a naming like
`internal(module)`, `internal(file)`

With this in mind, I wouldn't choose solution 2 from *Matthew* (prohibiting
`private` at some scope level), I would choose solution 1, with room for
renaming `fileinternal` in the future.


-- Antoine Cœur
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution