[swift-evolution] Revisiting SE-0041 Names

[Dave Abrahams]

on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Jun 27, 2016, at 8:29 AM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>>> 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.
>
> Starting with this:
>
>     "Conforming to a protocol is supposed to be a strong declaration
> about not just syntax, but semantics" - D. Abrahams

There's an exception to everything.  In this case, protocols used to
interface with the language at the lowest levels may be purely about
syntax.

> Current:
>
> 	/// Conforming types can be initialized with integer literals.
> 	public protocol IntegerLiteralConvertible {
>
> 	    associatedtype IntegerLiteralType
>
> 	    /// Create an instance initialized to `value`.
> 	    public init(integerLiteral value: Self.IntegerLiteralType)
> 	}
>
> Maybe my issue is that this should really read:
>
> 	/// Conforming types accept integer literal syntax for initialization
> 	/// allowing types to use integer literals in statements
> 	///
> 	/// ```
> 	/// let instance: T = *integer literal*
> 	/// ```
> 	/// 
> 	/// for example:
> 	/// 
> 	/// ```
> 	/// let myDouble: Double = 2 // The literal 2 is automatically
> cast
> 	/// let anotherDouble: Double = myDouble * 5 // The literal 5
> is automatically cast
> 	/// ```
> 	public protocol Syntax.SupportsIntegerLiteralValues {
>
>             /// For constrained integer literal types, which otherwise
> default to `Int`.
> 	    associatedtype IntegerLiteralType = Int
>
>              /// Create an instance initialized to `value`. 
> 	    ///  Required to enable in-line syntactic substitutions
> 	    public init(integerLiteral value: Self.IntegerLiteralType)
>
> 	}
>
> So a protocol of `Syntax.AcceptsIntegerLiteralValues` or
> `Syntax.AutoconvertsIntegerLiteralValues` might
> better explain what this is doing and the intent of the protocol. It
> ain't short but it's a hella lot clearer.

Being clear isn't helpful when it clearly implies the wrong meaning.
What's essential about this protocol neither that it “accepts” nor that
it “autoconverts” anything.  It's that it allows allows an integer
literal to be interpreted as an expression having the conforming type,
or to put it differently, it confers integer literal syntax upon the
conforming type.

-- 
Dave