> On Mar 14, 2016, at 11:05 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>
>> On Mar 10, 2016, at 9:19 AM, Joe Groff via swift-evolution
>> <[email protected]> wrote:
>>
>> For (A), we should look at the new places a generic type might appear in
>> expressions:
>>
>> - By itself:
>>
>> let x = Foo< T >
>> bar() // following statement
>>
>> let y = Foo< T, U >
>> bar() // following statement
>>
>> This doesn't strike me as a huge problem to parse as a type reference, since
>> 'a < b > c' is unlikely as an expression, and we don't have commas in the
>> top level of the grammar, so 'a < b, c > d' is impossible as a top-level
>> expression. Extending the lookahead rule to include `>;` or `> *token on
>> next line*` as disambiguators is probably OK.
>>
>> - As a function parameter, or array or dictionary element:
>>
>> sizeof(Foo<T>)
>> load(Foo<T>, atOffset: 8)
>> let types = [Foo<T>, Bar<U>]
>> let factories = [Foo<T>: makeFoo, Bar<U>: makeBar]
>>
>> This is probably the most common use case for type references, and the
>> easiest to support, since the parameters are always followed by a token that
>> can't start an expression by itself. We could extend the current lookahead
>> rule to ensure it includes `>)`, `>,` and `>:`.
>>
>> - As the parameter to an operator:
>>
>> ++Foo<T> // prefix
>> Foo<T>++ // postfix
>> Foo<T>+Bar<U> // infix
>> Foo<T> + Bar<U>
>> let foo = Bar<U>
>>
>> This one's a bit interesting since `>+` or `>++` could be operators
>> themselves. Applying operators to types might not be a compelling enough
>> reason to block the other changes, though.
>
> Well, comparison `>` is an infix operator. Could we treat generic parameter
> list `>` as a postfix operator? That is, require whitespace (or at least
> something that is neither operator nor identifier, like a parenthesis or dot)
> to its right but not its left? That would require looking all the way through
> the generic parameter list to the end, but we could bail early if we
> encounter something that can't be in a generic parameter list (as far as I
> can tell, that includes identifiers and dots, angle brackets and commas, and
> characters used in type shorthand).
Possibly. However, treating `>` as a postfix operator would conflict with the
current standard library formatting conventions, which prefer to split long
generic parameter lists K&R-style like this:
func foo<
T where...
>(
args...
) {
code...
}
-Joe_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
