on Wed Jun 22 2016, Matthew Johnson <[email protected]> wrote:
>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >> <[email protected]> wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> <[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. > > 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 >> <[email protected] >> <mailto:[email protected]>>*/ > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
