> When naming, we need to learn to stop treating the comfortable ring of > familiar word patterns as an arbiter of success.
I’m not sure I agree with this statement. I would argue we should most certainly aim to keep a consistent feel across our naming conventions, and furthermore, I think familiar word patterns greatly lowers barrier for entry for newcomers to the language. A big reason for so many of these renamings is because they don’t feel “Swifty”, and even if that might not be a good technical reason, I think it’s as valid a reason as any. Following that, “ExpressibleAsIntegerLiteral” feels extremely un-swifty, and while technically you could argue it follows the Swift API Guidelines, the fact that it’s the only protocol with the adjective at the beginning and not the end is a giant red flag to me (unless I’m missing some). A final thought: is it really better to have a technically correct name over one that, while technically incorrect, got its point across about how it should be used? This might just be me, but I would far prefer a name that from my interpretation would tell me how to use it, rather than one that would require me to think about what it actually means (as we’ve seen from all the confusion about what these protocols were actually doing). Overall though, I’m glad there is this much debate about the future of these names, I think it will leave us with the best name (eventually) :-) > On Jul 2, 2016, at 2:53 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > > on Sat Jul 02 2016, Riley Testut <rileytestut-AT-gmail.com > <http://rileytestut-at-gmail.com/>> wrote: > >> (My bad, accidentally hit send too early). >> >> That, or we could keep either the Convert or Express forms with >> "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we >> decide "express" really is the best word to describe what happens, I >> personally prefer "IntegerLiteralExpressing" to >> "ExpressibleAsIntegerLiteral", which doesn't feel at home with the >> other Swift protocol names. > > It doesn't matter if it “feels at home” if it has the wrong meaning. > It's not that Integer can express an integer literal; It's that an > integer literal can express an Integer. > > When naming, we need to learn to stop treating the comfortable ring of > familiar word patterns as an arbiter of success. > >> >> Riley >> >>> On Jul 2, 2016, at 10:49 AM, Riley Testut <rileytes...@gmail.com> wrote: >>> >>> I kinda agree that these names still aren't the best. FWIW, I much >>> preferred the originals, even if they could be misleading. >>> >>> What if we changed the names to be verbs instead of adjectives? Something >>> like "IntegerLiteralTransforming"? >>> >>>> On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote: >>>>> >>>>> -1 from me. I suggest to wait until we get generic protocols >>>>> in Swift 4, then we can use the following: >>>>> >>>>> protocol From<T> { >>>>> init(_ from: T) >>>>> } >>>>> >>>>> And deprecate all the weird Convertibles. >>>> >>>> Even if we could do that, “From” would never be an appropriate name for >>>> the ability to express a type as a particular kind of literal. >>>> >>>> -- >>>> -Dave >>>> >>>> _______________________________________________ >>>> 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
