[swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

[Dave Abrahams]

on Sat Jul 02 2016, Riley Testut <swift-evolution at swift.org> wrote:

>> 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).

I disagree fundamentally.  A component whose correct meaning cannot fit
sensibly into common word patterns *should* be named differently.  Even
if you somehow don't pay attention to word meanings and you *only* use
cues in the “sound” or “feel” of a name, being unlike other names is a
sign that it doesn't mean what you'd assume it does.

Being uniform is not as important as being expressive.

> 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).

Code is written more than it's read.  It's much more important for
someone to be able to read my declaration

   struct Set<T:Hashable> : ExpressibleAsArrayLiteral { ... }

and know what that means, than it is for someone to be able to see the
name of a protocol and somehow know “how to use it.”  I can't actually
think of a protocol more complicated than Equatable from which I could
reliably guess its proper usage from the name.

> 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 <dabrahams at 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 <rileytestut at 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 at swift.org> wrote:
>>>>> 
>>>>> 
>>>>>> on Sat Jul 02 2016, Anton Zhilin <swift-evolution at 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 at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> -- 
>> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave