[swift-evolution] [Proposal Draft] Literal Syntax Protocols

Stephen Canon scanon at apple.com
Wed Jun 29 09:05:15 CDT 2016

On Jun 29, 2016, at 9:33 AM, David Sweeris <davesweeris at mac.com> wrote:

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

There is at least an argument to be made that *division* doesn’t belong.  I think most people's common-sense notion of being “numbery” lies somewhere between a ring and a field (but probably doesn’t include the Sedenions, which aren’t associative).

That said, there are certainly some practical considerations in favor of including division in Arithmetic.

I think matrix dimension mismatches (for variably-dimensioned types) are best handled via precondition; the operator exists, but will trap if they don’t match.

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

I’m not sure it makes sense to have scalar initializers or literals for non-square matrices, since you don't have 1*x = x.

We’re a little bit off in the weeds here =)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/4a50bf50/attachment.html>

More information about the swift-evolution mailing list