> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On 22 Nov 2017, at 07:48, David Hart via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>>
>>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner <clatt...@nondot.org
>>>> <mailto:clatt...@nondot.org>> wrote:
>>>>
>>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgre...@apple.com
>>>> <mailto:dgre...@apple.com>> wrote:
>>>>>> Or alternatively, one could decide to make the generics system *only and
>>>>>> forever* work on nominal types, and make the syntactic sugar just be
>>>>>> sugar for named types like Swift.Tuple, Function, and Optional. Either
>>>>>> design could work.
>>>>>
>>>>> We don’t have a way to make it work for function types, though, because
>>>>> of parameter-passing conventions. Well, assuming we don’t invent
>>>>> something that allows:
>>>>>
>>>>> Function<Double, inout String>
>>>>>
>>>>> to exist in the type system. Tuple labels have a similar problem.
>>>>
>>>> I’m totally aware of that and mentioned it upthread.
>>>
>>> Eh, sorry I missed it.
>>>
>>>> There are various encoding tricks that could make this work depending on
>>>> how you want to stretch the current generics system…
>>>
>>> I think it’s straightforward and less ugly to make structural types allow
>>> extensions and protocol conformances.
>>
>> Can somebody explain to me what is less ugly about that? I would have
>> naturally thought that the language would be simpler as a whole if there
>> only existed nominal types and all structural types were just sugar over
>> them.
>
> What confuses me is that I always thought that T? was sugar for Optional<T>
> by design, and found that to be quite elegant. But now you’re telling me that
> its just a hack to allow conformance on Optionals until it can be made
> structural. I would have thought that it would be cleaner to have specific
> concepts (optionals, tuples, etc…) represented in terms of more general
> concepts (enum, struct) so that the compiler had less to reason about. I’m
> just trying to understand :-)
Don't worry too much about it. The people in this thread are conflating a lot
of different things, including some people who ought to know better. Your way
of looking at it is perfectly accurate.
A fairly standard formalization of types is that you have these type
expressions, which, in a simple system, are either type constants or type
applications.
A type constant is something like Int, Float, or Array. struct/enum/class
declarations in Swift all introduce new type constants, where each declaration
has its own identity as a type. Since we don't allow type names to be
redeclared in a scope, the identity of such declared types can be uniquely
determined by (1) the type's name in its scope and (2) the path to that scope.
Hence the identity is "by name", or "nominal".
A type application takes a generic type and applies it at some number of
arguments. The general syntax for this in Swift is <>. For example, Array is
a generic type, and Array<Int> is a type application of the generic type Array
with the argument Int. The arguments can be arbitrary type expressions, e.g.
Dictionary<String, Array<Float>>. The identity of a type application is
determined purely by its applicative structure: first, the identity of the
generic type being applied, and second, the identity of the type arguments it
is being applied to. That is, A<B> is the same type as C<D> as long as the
type-expression A is the same generic type as C and B is the same type as D.
Hence the identity is "structural".
(Formal nitpick: we're making some assumptions about the nature of type
expressions that generally work out until you get into really advanced type
systems.)
What is a tuple type in this formalization? Well, the rule we want is that (A,
B) is the same type as (C, D) if A is identical to C and B is identical to D.
We could add this as a special new rule to our definition of type expressions
above, but we don't really need to, because it turns out that it's exactly the
same as if we had some sort of tuple type constant — for sake of argument,
let's call it (...) — and allowed it to be applied to an arbitrary number of
types. Swift does not actually allow you to name this as an unapplied generic
type — you cannot write (...)<Int, Float> instead of (Int, Float) — but that's
just a matter of syntax. The fact that (...) is built into the language rather
than being declared in the standard library as Tuple is not fundamentally
significant. Nor is it fundamentally significant for Optional, which is
currently declared in the standard library instead of being built-in.
(Function types in Swift are weird because, as covered previously in this
thread, there's more to their structure than just component type identity. You
could still stretch the formalization to make this work, but, well, they'd
still be weird.)
Now, function, tuple, and optional types are special in the language in several
ways: there are primitive declarations and expressions that introduce or
manipulate these types, and there are special rules in the type system for
them. (For example, optionals and tuples obey covariant subtyping.) But we
could technically do the same for any type if we wanted to. We could even do
it to arbitrary third-party types as long as we handled the possibility that
they weren't imported into the current program.
We could absolutely allow tuples to conform to protocols without first
introducing variadic generics. We'd have to solve some straightforward
internal representation problems, and then we'd just need some way of spelling
them (if we didn't just hard-code a few conformances as special).
John.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
