[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