[Proposal Draft] Literal Syntax Protocols

Or we're clueless AND it's a bad name.

func f<T: IntegerPromotion>() -> T {
    return 42 // the answer to everything
}

-- E

···

On Jun 28, 2016, at 2:57 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
No, it's exactly the opposite, as I keep saying. Conformance to this
protocol does *not* mean you can initialize the type with a literal.
Proof:

func f<T: IntegerLiteralConvertible>() -> T {
   return T(integerLiteral: 43) // Error
   return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
   return 43 // OK
}

Everybody's confused about the meaning of the protocol, and doesn't like
the proposed names because they imply exactly the actual meaning of the
protocol, which they misunderstand.

Nate

I like the namespace-based approach to group these protocols together
and I'm very happy to see some clarification happening in this group
of protocols. However, I don't think the proposed new names
communicate what they need to. The names listed in the "Alternatives
Considered" section do a better job of describing the use and behavior
of these protocols.

Primarily, the new names read like we're saying that a conforming type
is a literal, compounding a common existing confusion between literals
and types that can be initialized with a literal.

No, it's exactly the opposite, as I keep saying. Conformance to this
protocol does *not* mean you can initialize the type with a literal.

Fair enough! The point I'm most concerned about is that there is confusion (among the populace at large, less so on this list) between literals and types that can be written as literals. The number 43 is an integer literal, not an `Int` - its type is either inferred from context or given explicitly. Some kind of adjective in the protocol name would make that more clear than removing the adjective.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
   return T(integerLiteral: 43) // Error
   return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
   return 43 // OK
}

Everybody's confused about the meaning of the protocol, and doesn't like
the proposed names because they imply exactly the actual meaning of the
protocol, which they misunderstand.

I resemble this remark.

Nate

···

On Jun 28, 2016, at 3:57 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu Jun 23 2016, Nate Cook <swift-evolution@swift.org> wrote:

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

No, it's exactly the opposite, as I keep saying. Conformance to this
protocol does *not* mean you can initialize the type with a literal.
Proof:

func f<T: IntegerLiteralConvertible>() -> T {
   return T(integerLiteral: 43) // Error
   return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
   return 43 // OK
}

Everybody's confused about the meaning of the protocol, and doesn't like
the proposed names because they imply exactly the actual meaning of the
protocol, which they misunderstand.

Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
    return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

···

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

On Jun 28, 2016, at 2:57 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

--
Dave

Next pitch:
Syntax.IntegerLiteralInsertion
Less successful attempts to brainstorm:
Syntax.IntegerLiteralAdvancement
Syntax.IntegerLiteralUpgrade
Syntax.FreelyIntegerReplaceable
Syntax.IntegerParkour
Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
Syntax.IntegerLiteralTypePoseur
Syntax.IntegerLiteral.Zigazigahh
Syntax.IntegerLiteralBoosterPack
Syntax.IntegerLevelUp
Syntax.IntegerElevator
Syntax.MarvinTheDepressedIntegerLiteral
-- E

···

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com> wrote:

Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Next pitch:
Syntax.IntegerLiteralInsertion
Less successful attempts to brainstorm:
Syntax.IntegerLiteralAdvancement
Syntax.IntegerLiteralUpgrade
Syntax.FreelyIntegerReplaceable
Syntax.IntegerParkour
Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
Syntax.IntegerLiteralTypePoseur
Syntax.IntegerLiteral.Zigazigahh
Syntax.IntegerLiteralBoosterPack
Syntax.IntegerLevelUp
Syntax.IntegerElevator
Syntax.MarvinTheDepressedIntegerLiteral

You really have me laughing with some of these! Thanks Erica. :)

···

On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I vote for IntegerParkour :-)

···

Sent from my iPhone

On Jun 28, 2016, at 20:35, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com> wrote:
Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Next pitch:
Syntax.IntegerLiteralInsertion
Less successful attempts to brainstorm:
Syntax.IntegerLiteralAdvancement
Syntax.IntegerLiteralUpgrade
Syntax.FreelyIntegerReplaceable
Syntax.IntegerParkour
Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
Syntax.IntegerLiteralTypePoseur
Syntax.IntegerLiteral.Zigazigahh
Syntax.IntegerLiteralBoosterPack
Syntax.IntegerLevelUp
Syntax.IntegerElevator
Syntax.MarvinTheDepressedIntegerLiteral
-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

A few more, with a slightly different approach that pushes the literal part towards the end of the name:
Syntax.SupportsIntegerLiterals
Syntax.AcceptsIntegerLiterals
Syntax.IncludesIntegerLiterals
Syntax.IncorporatesIntegerLiterals

···

On Jun 28, 2016, at 7:52 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Syntax.MarvinTheDepressedIntegerLiteral

You really have me laughing with some of these! Thanks Erica. :)

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

l8r
Sean

···

Sent from my iPad

On Jun 28, 2016, at 8:52 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com> wrote:
Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Next pitch:
Syntax.IntegerLiteralInsertion
Less successful attempts to brainstorm:
Syntax.IntegerLiteralAdvancement
Syntax.IntegerLiteralUpgrade
Syntax.FreelyIntegerReplaceable
Syntax.IntegerParkour
Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
Syntax.IntegerLiteralTypePoseur
Syntax.IntegerLiteral.Zigazigahh
Syntax.IntegerLiteralBoosterPack
Syntax.IntegerLevelUp
Syntax.IntegerElevator
Syntax.MarvinTheDepressedIntegerLiteral

You really have me laughing with some of these! Thanks Erica. :)

-- E

_______________________________________________
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

If you want to pick out your favorites I’ll be happy to update the proposal to include them in the alternatives section.

···

On Jun 28, 2016, at 9:05 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 7:52 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 28, 2016, at 6:13 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot. If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

func f<T: IntegerPromotion>() -> T {
   return 42 // the answer to everything
}

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

Syntax.MarvinTheDepressedIntegerLiteral

You really have me laughing with some of these! Thanks Erica. :)

A few more, with a slightly different approach that pushes the literal part towards the end of the name:
Syntax.SupportsIntegerLiterals
Syntax.AcceptsIntegerLiterals
Syntax.IncludesIntegerLiterals
Syntax.IncorporatesIntegerLiterals

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
   return T(integerLiteral: 43) // Error
   return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
   return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

···

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

···

Sent from my iPad

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
  return T(integerLiteral: 43) // Error
  return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
  return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

···

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

Arg. Dang it!

Syntax.ExpressibleAsIntegerLiteral
Syntax.FromIntegerLiteral
Syntax.IntegerLiteralManifestation
Syntax.GhostOfIntegerLiteral
Syntax.FormerlyKnownAsIntegerLiteral

l8r
Sean

···

Sent from my iPad

On Jun 28, 2016, at 10:29 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal,

**Which is almost exactly the right interpretation, as I keep pointing
out.** How can this be considered a valid argument against that name?

···

on Tue Jun 28 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

not that an integer literal can be expressing the type.
(I won't even bring up other associations for that word since most of
the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

Semi-serious question for integer literals in particular: do we need a separate protocol at all? Are there types we want to support where integer literals should be supported, but + doesn't make sense? Where 1+1 actually isn't 2?

If not, are integer literals really just part of Arithmetic?

- Steve

···

On Jun 28, 2016, at 11:21 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Sent from my iPad

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I’m honestly shocked that y’all (that I’ve seen) haven’t come up with Syntax.LiterallyIntegerLiteral yet.

···

On Jun 28, 2016, at 8:39 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

Arg. Dang it!

Syntax.ExpressibleAsIntegerLiteral
Syntax.FromIntegerLiteral
Syntax.IntegerLiteralManifestation
Syntax.GhostOfIntegerLiteral
Syntax.FormerlyKnownAsIntegerLiteral

l8r
Sean

Sent from my iPad

On Jun 28, 2016, at 10:29 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Now that's just silly!

l8r
Sean

···

Sent from my iPad

On Jun 28, 2016, at 10:49 PM, Greg Titus <greg@omnigroup.com> wrote:

I’m honestly shocked that y’all (that I’ve seen) haven’t come up with Syntax.LiterallyIntegerLiteral yet.

On Jun 28, 2016, at 8:39 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

Arg. Dang it!

Syntax.ExpressibleAsIntegerLiteral
Syntax.FromIntegerLiteral
Syntax.IntegerLiteralManifestation
Syntax.GhostOfIntegerLiteral
Syntax.FormerlyKnownAsIntegerLiteral

l8r
Sean

Sent from my iPad

On Jun 28, 2016, at 10:29 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Arg. Dang it!

Syntax.ExpressibleAsIntegerLiteral

+1

IMO it's not possible to improve on that one.

···

on Tue Jun 28 2016, Sean Heber <swift-evolution@swift.org> wrote:

Syntax.FromIntegerLiteral
Syntax.IntegerLiteralManifestation
Syntax.GhostOfIntegerLiteral
Syntax.FormerlyKnownAsIntegerLiteral

l8r
Sean

Sent from my iPad

On Jun 28, 2016, at 10:29 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

Types where it makes sense, or types for which such semantics would be a good idea? Because, for example, you could do something like this:
struct HTMLParser : IntegerLiteralConvertible {
    init(integerLiteral value: IntegerLiteralType) {
        htmlMajorVersion = value
        htmlMinorVersion = 0
    }
}

Back in the realm of math, I don’t think Sedenions — a 16-demensional (in the sense that complex numbers are 2-dimensional) number — have a well-defined division operator.

As a more likely example, I don’t think it’d be too much of a stretch to attach integer literal semantics to matrices:
let x: Matrix = 1 // Sets diagonal to 1
Matrices don’t have a division operator, and you can’t do any of the `Arithmetic` functions to two matrices without first checking their dimensions. Plus, inherently-dimensioned matrix types:
var x = Matrix<_2,_3>() // "_2" and "_3" are dummy types
can’t implement `*`, unless their two dimensions happen to be equal — "Matrix<2,3>() * Matrix<2,3>()” doesn’t have a valid definition.

- Dave Sweeris

···

On Jun 29, 2016, at 7:49 AM, Steve Canon via swift-evolution <swift-evolution@swift.org> wrote:

Semi-serious question for integer literals in particular: do we need a separate protocol at all? Are there types we want to support where integer literals should be supported, but + doesn't make sense? Where 1+1 actually isn't 2?

If not, are integer literals really just part of Arithmetic?

- Steve

And just as a side note: the example does work like this:

func f<T : IntegerLiteralConvertible>() -> T {
    return T(integerLiteral: 43 as! T.IntegerLiteralType) // Error
}

func g<T : IntegerLiteralConvertible where T.IntegerLiteralType == Int>() -> T {
     
    return T(integerLiteral: 43)
}

let test: Int = f()
let test2: Int = g()
I assume everyone does know that. The example by itself shows us that literals are in fact typeless until they’re converted into a real type.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 08:48:30, Dave Abrahams via swift-evolution (swift-evolution@swift.org) schrieb:

on Tue Jun 28 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 9:21 PM, Sean Heber <sean@fifthace.com> wrote:

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Aaaaaand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal,

**Which is almost exactly the right interpretation, as I keep pointing
out.** How can this be considered a valid argument against that name?

not that an integer literal can be expressing the type.
(I won't even bring up other associations for that word since most of
the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E

On Jun 28, 2016, at 10:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 28, 2016, at 8:08 PM, Sean Heber <sean@fifthace.com> wrote:

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

Conformance to this protocol does *not* mean you can initialize the type with
a literal.

Proof:

func f<T: IntegerLiteralConvertible>() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}

It means an instance of the type can be *written* as a literal:

func f<T: IntegerLiteralConvertible>() -> T {
return 43 // OK
}

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E

_______________________________________________
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