Sent from my iPad
> On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > Before I start revising this proposal, there are a couple of open questions > I’d like to discuss with the community and the core team. > > The first question relates to the purpose of having a “internal” argument > name. There are applications of such names in GADT (if we ever get there) and > perhaps the case-as-subtype-of-the-enum stories on the list right now. Out > side of these scenarios, however, such names has few chances to be used. The > one I can come up with, which is also the “open” part of the question, is > this: we can use the internal names in pattern matching, as opposed to using > the labels. This seems to align with the subtyping/GADT use cases. Is this a > desirable outcome? This is what I suggested. I think of it like this: the case includes a static factory method that produces values. We obviously want the external label here. The pattern is like matching a labeled tuple. When we think of the cases as a labeled tuple (or synthesized struct in the case-as-subtype world) it is clear (to me at least) that we want to use the internal name. To avoid the noise, I suggest allowing patterns to elide the label if they bind to an identical name, which is often what they will do. > > The second open question is the syntax for “overloaded” cases. If we decide > to allow them, what should the patterns matching them look like? I can think > of one obvious-ish design where we make the pattern look like the declaration > and require types for disambiguation. So the most verbose form of pattern > would look something like > > ``` > case let .baseName(label0 name0: Type0, label1 name1: Type1) > ``` We don't need new syntax for this. Cast patterns in the associated value slots should work just fine: case let .baseName(name0 as Type0, name1 as Type1) Here, `name0` and `name1` are the internal names of the pattern. If the pattern had different internal names the label must be used: case let .baseName(internalName1: name0 as Type0, internalName2: name1 as Type1) Note: the syntactic sugar of eliding the label should also be allowed in cases that don't don't distinguish the internal and external names. > > Even in this design, there are the choice of forcing name0/name1 to match the > “internal” name in declaration and letting users choose whatever they want. > There maybe way elegant syntax that I haven’t thought of. Since my experience > with languages with pattern matching syntax is pretty much limited to SML and > Haskell, I must admit my inadequacy here. Any help is appreciated here! > > >>> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> My apologies for misunderstanding. >>> >>> Would it be better to add the anonymous case feature in a separate >>> proposal? It stands alone as a new addition to enum. The intent for this >>> proposal is bringing enum's syntax closure to other part of Swift. >> >> The core team met and talked about SE-0155 today, even though we're not >> quite done with the review period, and here's where we stand. >> >> SE-0155 is being returned for revision. Consensus appears to be strongly in >> favor of requiring argument labels (if provided) to be enforced on "call" >> sites. However, the core team feels that the proposal needs revision in the >> following ways: >> - Are internal argument names syntactically allowed in a case declaration? >> - Can cases with the same base name be overloaded by argument label? If >> so, is a pattern match using just the bare name ambiguous or does it match >> both cases? >> - Can cases with the same name (using the same rule as above) be >> overloaded by argument type? If so, how are they disambiguated in pattern >> matches? >> - Do pattern matches require argument labels to be given along with value >> patterns, e.g. "case .valid(value: let value)", or is there some way to >> shorten this? If the latter, what are the rules for that? >> - Are you proposing anonymous cases, and if so, what are the language >> rules for them? >> - The proposal makes a claim about layout efficiency; please either >> discuss this claim or remove it. >> >> John. >> >>> >>> Daniel Duan >>> Sent from my iPhone >>> >>>> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> I had not intended for _ to be an ordinary identifier, but as a way of >>>> spelling the empty case name. Ambiguous cases, not distinguished by either >>>> full name or payload type, would be errors. How to construct anonymous >>>> cases? I guess it would be MyEnum(expression) >>>> >>>> Sent from my moss-covered three-handled family gradunza >>>> >>>>> On Feb 19, 2017, at 2:52 PM, Daniel Duan <dan...@duan.org> wrote: >>>>> >>>>> >>>>>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>>>>>> <swift-evolution@swift.org> wrote: >>>>>>> >>>>>>> >>>>>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >>>>>>> <swift-evolution@swift.org> wrote: >>>>>>> >>>>>>> I'm on vacation and don't have time for a full review right now, but I >>>>>>> am concerned that wild this proposal would make enums more general and >>>>>>> uniform with the rest of the language , they also would become much >>>>>>> more awkward for common use cases. I have recently been very pleased >>>>>>> that I didn't have to supply labels in switch statements where the >>>>>>> label name would simply have matched the name of the variable to be >>>>>>> bound. This looks needlessly verbose: >>>>>>> >>>>>>> case .valid(value: let value, resumptionPoint: let resumptionPoint): >>>>>>> >>>>>>> I cannot imagine a real life use case where one would have labels in >>>>>>> the case and desire to bind associated values to variables having >>>>>>> different names than the labels. >>>>>> >>>>>> I agree with this, but I think it’s an issue we can solve (perhaps as an >>>>>> amendment to this proposal). >>>>>> >>>>>> First, I think Brent’s idea of introducing an argument label that can be >>>>>> distinct from the “property” name of the case is a good one. I think we >>>>>> should do this. It takes the parallel with function signatures even >>>>>> further. >>>>>> >>>>>> Second, we should allow the “property” name to be `_`. This would mean >>>>>> no label can be used when matching: >>>>>> >>>>>> case valid(value _: ValueType, resumptionPoint _: PointType) >>>>>> >>>>>> Third, I think we should also allow suers to elide the label if they >>>>>> either discard the value with `_` or bind a name that is identical to >>>>>> the label, so we might have: >>>>>> >>>>>> // declaration: >>>>>> case valid(externalCasConstructorLabel value: ValueType, >>>>>> externalCaseConstructorLabel resumptionPoint: PointType) >>>>>> >>>>>> // match ok: >>>>>> case .valid(let value, let resumptionPoint): >>>>>> >>>>>> // error, names do not match: >>>>>> case .valid(let foo, let bar): >>>>>> >>>>>> // ok, label is used: >>>>>> case .valid(value: let foo, resumptionPoint: let bar): >>>>>> >>>>>> This follows the behavior of function signatures very closely. The >>>>>> external label is used to provide context for the argument at the call >>>>>> site (of the case constructor). The internal name is used to bind a >>>>>> name to the value that is used by code that works with the value. >>>>>> >>>>>> The only exception here is that because the usage site is distant from >>>>>> the case declaration it may wish to use a different name. We allow >>>>>> that, but only if the “internal name” is also used in the pattern. This >>>>>> preserves the ability of a reader of the code to see the name / meaning >>>>>> of the associated value as it was declared by the enum in addition to >>>>>> the name that might make more sense for use in the local context. >>>>>> >>>>>>> >>>>>>> Secondly, I can't imagine a case where one would want to use the same >>>>>>> case basename and different labels. The very common use case where the >>>>>>> types of associated values completely distinguish the case and one >>>>>>> would rather not have to supply a case name at all is completely >>>>>>> unaddressed. If my quick read is not mistaken, this proposal makes it >>>>>>> legal for cases to have different complete names (including base name >>>>>>> and labels), but doesn't make it legal to have the same full name >>>>>>> (which I would love to be "_" or missing in some cases) with different >>>>>>> associated value types. If we were truly following the precedent set by >>>>>>> function signatures, wouldn't that be possible too? >>>>>> >>>>>> +1. I think this makes a lot of sense. It completes the parallel of >>>>>> cases with overloaded functions. >>>>>> >>>>>> I think anonymous cases are a really good idea. I discuss those quite a >>>>>> bit in the value subtyping manifesto I shared last week (I’d love to >>>>>> hear your thoughts on it if / when you have time to take a look). >>>>>> >>>>>> How would you propose that values of anonymous cases be constructed and >>>>>> matched? My solution is to allow them to be constructed by implicit >>>>>> conversion from the associated value type to the enum type and matched >>>>>> by a cast pattern. Is that what you have in mind? I would *really* >>>>>> love to see this someday... >>>>> >>>>> I can’t speak for Dave obviously. But I think he was merely proposing >>>>> “overloaded” form of enum options, in which multiple options may share >>>>> the compound name but with differently associated types. The name “_” >>>>> would just be a normal identifier in such scenario. So it would also be >>>>> the contractor’s function name. >>>>> >>>>>>> >>>>>>> Sent from my moss-covered three-handled family gradunza >>>>>>> >>>>>>>> On Feb 17, 2017, at 5:26 PM, John McCall <rjmcc...@apple.com> wrote: >>>>>>>> >>>>>>>> Hello Swift community, >>>>>>>> >>>>>>>> The review of "SE-0155: Normalize Enum Case Representation" begins now >>>>>>>> and runs through next Friday, February 26th. The proposal is available >>>>>>>> here: >>>>>>>> >>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >>>>>>>> >>>>>>>> Reviews are an important part of the Swift evolution process. All >>>>>>>> reviews should be sent to the swift-evolution mailing list at >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> or, if you would like to keep your feedback private, directly to the >>>>>>>> review manager. When replying, please try to keep the proposal link at >>>>>>>> the top of the message: >>>>>>>> >>>>>>>> Proposal link: >>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >>>>>>>> >>>>>>>> Reply text >>>>>>>> >>>>>>>> Other replies >>>>>>>> >>>>>>>> What goes into a review? >>>>>>>> >>>>>>>> The goal of the review process is to improve the proposal under review >>>>>>>> through constructive criticism and, eventually, determine the >>>>>>>> direction of Swift. When writing your review, here are some questions >>>>>>>> you might want to answer in your review: >>>>>>>> >>>>>>>> • What is your evaluation of the proposal? >>>>>>>> • Is the problem being addressed significant enough to warrant >>>>>>>> a change to Swift? >>>>>>>> • Does this proposal fit well with the feel and direction of >>>>>>>> Swift? >>>>>>>> • If you have used other languages or libraries with a similar >>>>>>>> feature, how do you feel that this proposal compares to those? >>>>>>>> • How much effort did you put into your review? A glance, a >>>>>>>> quick reading, or an in-depth study? >>>>>>>> >>>>>>>> More information about the Swift evolution process is available at >>>>>>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> John McCall >>>>>>>> Review Manager >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution-announce mailing list >>>>>>>> swift-evolution-annou...@swift.org >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
