on Mon Jun 27 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson <[email protected] > >> <mailto:[email protected]>> wrote: >> >>>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >>>> <[email protected] <mailto:[email protected]> >>> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>> wrote: >>>>> Proposal: >>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md >>>>> >>>>> Rejection: "The feedback on the proposal was generally positive about the >>>>> idea of renaming these protocols, but the specific names in the proposal >>>>> are >>>>> not well received, and there is no apparent confluence in the community on >>>>> better names. The core team prefers discussion to continue -- if/when >>>>> there >>>>> is a strong proposal for a better naming approach, we can reconsider >>>>> renaming these." >>>>> >>>>> John McCall: "To be clear, I don't care about the name. If you want to >>>>> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't >>>>> drag >>>>> the conversation into the muck again. :) It's the design of the >>>>> requirements that I'm pretty opposed to revisiting." >>>>> >>>>> The Problem: This is really the last chance to rationalize this across the >>>>> language and to evaluate whether other protocol groups should have a core >>>>> scheme for naming. >>>> >>>> Hi Erica, >>>> >>>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev >>>> and me from the last time this was discussed. Unfortunately I can't >>>> find the exact email, so I can't provide a link. >>>> >>>> - The "literal" protocols are not about conversion, they are about >>>> adopting a certain syntax provided by the language. "Convertible" in >>>> the name is a red herring: a type can't be convertible from an integer >>>> literal because there is no "IntegerLiteral" entity in the type >>>> system. The literal *becomes* typed as the corresponding literal type >>>> (e.g., Int or String), and as far as the user at the call site is >>>> concerned, there is no visible conversion (even if one is happening >>>> behind the scenes). >>>> >>>> Our suggestion was to focus on the "adopting the syntax" part. We >>>> suggested moving the "literal convertible" protocols into a >>>> pseudo-namespace "Syntax". It could be implemented like this: >>>> >>>> protocol _IntegerLiteralSyntax {} >>>> enum Syntax { >>>> typealias IntegerLiteral = _IntegerLiteralSyntax >>>> } >>>> >>>> And used like this: >>>> >>>> struct Int : Syntax.IntegerLiteral {} >>> >>> I’m working on a draft of this proposal right now. I have a couple >>> questions. >>> >>> First, I’d like to list the standard library team as co-authors if you >>> desire because this is really your idea. Let me know what you would >>> prefer. >>> >>> Second, I wonder if it might make more sense to name the protocols >>> `Syntax.IntegerLiteralInitializable`. Dave has opposed >>> `Initializable` as a general convention because it implies pure syntax >>> and doesn’t carry any semantics. But in this case the semantics *are* >>> essentially the syntax. Erica pointed out to me off list that at the >>> usage site the `Syntax.IntegerLiteral` names could confuse somebody >>> into thinking in terms of *isa* rather than *can do* (i.e. Int is an >>> IntegerLiteral rather than Int can be *initialized* with an >>> IntegerLiteral). >> >> Really, this is exactly the sense in which we want it to be interpreted. >> It is *not* a capability. There is no such thing as an IntegerLiteral >> instance from which one can initialize an Int. There are only syntactic >> integer literals, which, given the right type context, can be-a Int. >> The intializer one gets from the protocol is merely the mechanism used >> by the compiler to create this Int. > > That is a technically correct statement, but I think the model most > programmers will have (good or bad) is of initializing with an integer > literal. I think this is evidenced to some degree by the feedback > people are providing on the names. Yes, that's a very strong reason not to name the protocols so as to encourage that misinterpretation. :-) > That said, I am trying to stay out of the fray of the bike shedding on > this. IMO the most important thing is to do *something* here as long > as its reasonable and the solution suggested by the standard library > team is definitely reasonable. That is why I have written the > proposal exactly as the standard library team suggested. :) Thank you. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
