> On Aug 29, 2017, at 2:21 PM, David Sweeris <daveswee...@mac.com> wrote:
>
>
>> On Aug 29, 2017, at 1:49 PM, Slava Pestov <spes...@apple.com
>> <mailto:spes...@apple.com>> wrote:
>>
>>
>>> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev
>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>
>>> Hi everyone! I'm trying to implement literal values as generic types.
>>
>> Can you briefly explain what you mean by this?
>>
>> Are you referring to let-polymorphism, like
>>
>> let fn = { $0 }
>> let f1: (Int) -> Int = fn
>> let f2: (Float) -> Float = fn
>
> No, I mean so that a vector's or matrix's dimensions can be part of its type
> (strawman syntax and protocol name, but this is pretty much what I'll be
> trying to support, at least at first):
I think instead of modeling these generic parameters as types, you should look
into generalizing GenericSignatures to contain ‘literal requirements’. Right
now, we have four kinds of requirements:
- A is a subclass of B
- A conforms to B
- A is the same type as B
- A has a known layout
All of these except for the last one have a generic parameter as their right
hand side. All of them have a generic parameter on their left hand side. I
think what you want is to add a new ‘value parameter’ that is not a type, but
instead has a value. Requirements would be placed on these to constrain them to
known kinds of literals (integers, strings, etc).
> struct Vector<T: ExpressibleByIntegerLiteral, L: IntegerLiteralExpr> {
> var elements: [T]
> init() {
> elements = [T](repeating: 0, count: L)
> }
> }
>
> let vect = Vector<Int, 5>()
>
> And, once that's working, I'm going to add support simple "type functions":
> func join <T, L1, L2> (_ lhs: Vector<T, L1>, _ rhs: Vector<T, L2>) ->
> Vector<T, L1 + L2 > {...}
> I think restricting the supported "type functions" to expressions that could
> be evaluated by the compiler's "constant folding" code would be a reasonable
> place to start,
The compiler’s constant folding operates on SIL instructions, not Exprs
directly. However constant folding is not generally what you want for this,
because constant folding is a ‘best effort’ kind of optimization (it may or may
not fold your calculation down to a constant) and also it produces code that
evaluates the result (even if its a constant) and not the result itself.
I think if you want to explore type-level computation like this, you should
define a very small subset of the language which can be computed by the type
checker like this.
> until we figure out what we want to do about "pure"/"constexpr" stuff... even
> just "+" for numeric and string literals, and "-" for numeric literals, seems
> like a reasonable starting goal, and I think that'd be simple enough to
> implement (famous last words, right?)... It's all academic until I get the
> simple cases working first, though.
>
> Anyway, I think it'll be worth writing up as a proposal, once it's working
> and I've figured out how to present these "literal types" to Swift's type
> system (I'd like to keep it as a literal of some sort, so that, say, `L` in
> this example could be used to set the value of any type that conforms to
> `ExpressibleByIntegerLiteral`).
>
> - Dave Sweeris
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
