Regards LM (From mobile)
> On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson <swift-evolution@swift.org> wrote: >> >>>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >>>> <griboz...@gmail.com> wrote: >>>> >>>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org >>> >>>> <mailto:swift-evolution@swift.org>> >>>> 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. Perpetuating the wrong idea does not make it a good idea... There was Ptolemy and then there was Galileo. > 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. :) > >> >>> >>> Please let me know if this name change would be acceptable to the >>> standard library team or may be met with resistance. I want this >>> proposal to be acceptable to the team from the start. >>> >>> Matthew >>> >>>> >>>> - For protocols that are representing conversions between types that >>>> actually exist in the library, there is not enough precedent yet to >>>> make a general conclusion and standardize a pattern. >>>> >>>> Dmitri >>>> >>>> -- >>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if >>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko >>>> <griboz...@gmail.com >>>> <mailto:griboz...@gmail.com>>*/ >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> -- >> -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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution