[swift-dev] Advice for implementing "literal values as generic types"

[Slava Pestov]

> On Aug 29, 2017, at 2:21 PM, David Sweeris <davesweeris at mac.com> wrote:
> 
> 
>> On Aug 29, 2017, at 1:49 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>> 
>>> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170829/3aa9e10f/attachment.html>