For @tupleLiteral
, you mentioned that the init signature would be the tuple literal, but it might be a little inconsistent with the other attributes for those being the argument for the designated initializer. i.e. :
// integer literal
struct Integer {
// Notice that the literal value is the argument
@integerLiteral
init(integerLiteral value: Int) {}
}
let int: Integer = 0
// tuple literal
struct X {
// Literal value here is the initializer itself
@tupleLiteral
init(y: Int, z: Bool) {}
}
let x: X = (y: 0, z: true)
// vs.
struct X {
// Tuple literal is the argument
@tupleLiteral
init(tupleLiteral value: (y: Int, z: Bool)) {}
}
let x: X = (y: 0, z: true)
Also, @tupleLiteral
initializers would be kind of awkward with types that have a single argument (single argument tuples with labels are banned):
// Silly example, but maybe there are use cases
// for a single argument tuples
struct BoolWrapper {
@tupleLiteral
init(bool: Bool) {}
}
// error: cannot create a single-element tuple
// with an element label
let boolThing: BoolWrapper = (bool: true)
These are just some design thoughts I had after the discussion because I might be interested in toying around with this when I get the chance.