> On Jan 27, 2017, at 11:55 AM, Robert Widmann <[email protected]> wrote:
>
>
>
> ~Robert Widmann
>
> 2017/01/26 13:37、Daryle Walker <[email protected] <mailto:[email protected]>>
> のメッセージ:
>
>>
>>> On Jan 23, 2017, at 3:33 PM, Robert Widmann <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Some thoughts inline.
>>>
>>>> On Jan 21, 2017, at 11:06 AM, Daryle Walker via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> 1. Variadic generics
>>>>
>>>> When I look at SwiftDoc.org <http://swiftdoc.org/>, I see some functions
>>>> repeated with differing numbers of parameters. This seems like a job for
>>>> variadic templates^H^H^H^H^H^H^H^H^H generics, like in C++. Fortunately,
>>>> someone has already wrote about this, at
>>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
>>>>
>>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics>>.
>>>> A new idea I came up with is that both homogeneous (the current support)
>>>> and heterogeneous variadic parameters can appear in function declarations.
>>>> Each can appear at most once in a declaration. And they can co-exist in
>>>> the same declaration; there’s no problem unless the two packs are adjacent
>>>> and at least the (lexically) second one doesn’t mandate a label. In that
>>>> case, and when the homogenous pack appears second, count from the
>>>> lexically last argument backwards until an argument cannot be part of the
>>>> homogeneous type, that’ll be the border. Count the other way when the
>>>> homogenous pack is first. (It’s possible for one pack to have zero
>>>> elements.)
>>>
>>> C++ has a simpler rule (for once): If you’re going to pack, you have to
>>> pack last. This is roughly the rule we have as well for argument lists in
>>> functions that don’t have labels - they can have any number of variadic
>>> parameters because we can use the argument label to guide the tuple type
>>> comparison and disambiguate. Here we lack argument labels (and I’m not
>>> sure it’s useful to have them).
>>>
>>> As for the distinction between heterogeneous and homogenous lists, I’m not
>>> sure it’s a useful thing to have unless you’re trying to roll your own
>>> Tuple (which is a thing you can do now with HLists
>>> <https://github.com/typelift/Swiftz/blob/master/Sources/HList.swift>
>>> anyway). Any type that wishes to take a variadic number of homogeneous
>>> type variables is a type that can be parametrized by one type variable and
>>> enforce the cardinality invariant elsewhere (see std::initializer_list).
>>>
>>
>> The “homogenous list” I’m talking about are the variadic parameters that are
>> already in the language. And they can already be non-last in the list. (At
>> least it compiled, but the parameter I had after it had a default value, so
>> I don’t know if that made a difference.)
>
> A warning was just introduced if you declare non-terminal variadics without
> argument labels to disambiguate parameters. That's what I meant. Being able
> to constrain a signature so that it must have at least a certain cardinality
> seems useful, but what I’m saying is I’m not sure it’s useful to constrain it
> in multiple directions. Consider
Just checked with a Playground; it’s actually an error. But seeing this:
> struct Foo<T, U, V…, LAST> {}
>
> which can be instantiated as Foo<String, Int, UInt, NSObject> to satisfy the
> requirements of the signature. Rearranging this declaration to shuffle
> non-variadic parameters to the front doesn’t change that
>
> struct Foo<T, U, LAST, V...> {}
>
> It just changes the order in which you or the typechecker comes around to
> instantiate the signature. We’re getting down to matters of practicality
> here: Yes, there’s nothing stopping us from allowing variadics in any
> position, but what’s the point? What kinds of structures can I only model
> with this kind of bi-directional cardinality matching?
I’m not writing about variadic parameters within “<>”…
>> The “homogenous” is to differentiate them from parameters introduced by
>> variadic generics (which would be “heterogeneous”).
>
> Ah, so there’s not a hard difference here just a terminology change. The use
> of “homogenous” and “heterogeneous” here is superfluous, since it’s pretty
> much assumed that in a variadic setting you wish for a heterogeneous list of
> types. After all, by linearity, Foo<T, T, T, T…> is isomorphic to Foo<T>.
…but within the “()”. I think we’ve been writing at cross-purposes. I’m talking
about functions like:
func test1<...T>(myIntegers: Int…, _ myT: T…)
or
func test2<...T>(_ myT: T…, _ integers Int…)
and finding the line between the “Int” list (homogenous and “()”-level) and “T”
list (heterogenous and originally “<>”-level). But now I know these cases are
already banned, so don’t worry about it.
I wasn't considering homogenous arguments within “<>” (assuming variadic
generics are added), since those would be a case within heterogenous arguments,
as you said.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
