Supporting Extensions for Structural Types

DevAndArtist · February 20, 2019, 5:36pm

Aside the problem you have mentioned which I also dislike and wish we had Type<T> type for one part of the metatypes, you can workaround your issue:

var someData = [AnyHashable: String]()
someData[ObjectIdentifier(Int.self)] = "integer"

eaplatanios · February 21, 2019, 2:28pm

Thanks @yxckjhasdkjh! I agree with you. In this case, it would be great if someone could answer the following couple questions:

What is it that makes extending tuples hard right now? Why are tuples not represented as structs?
What would it take to add support for this feature, without worrying about variadic generics for now? Are there some good starting points about where to look and what needs to change?

Nevin · February 21, 2019, 3:57pm

DevAndArtist:

Any syntax for that feature is fine by me. I'm just worried about the postfix operator because it will read ambiguous in functions regardless of the ugliness of any these operators.
func foo(_: Int...) {} // variadic `Int` and only `Int`

struct R<T...> {
   func bar(_: T...) {} // Is it now a variadic list of only `T` or all T's?
}
struct S<...T> {
   func bar(_: ...T) {}
}
If there is no ambiguousness for the former form then I guess I can live with it, but it will require some mind-bending, because if you missed the parameter list from the type it's not clear what T... in the function really means until you check the original T .

In struct R<T...>, there is no single type “T”, so the func bar(_: T...) must take all the generic types “T...”. There is no meaning to “a variadic argument list of just type T”, because there is no type T.

I don’t know what (if any) syntax there will be for enumerating the individual types within T..., but if we use a strawman of indexing into T then you might be able to write, eg:

func bar(_: T[0]...)

(Which would presumably crash at runtime if T... is empty.)

DevAndArtist:

Consider these two types where the operators have different meanings.

struct A<...T> {}
let a: A<Int, String, Bool> = ...

struct B<T...> {}
let b: B<Int, Int, Int> = ...
let invalid_b: B<Int, String> = ... // error `T` must be of the same type.

Requiring that multiple generic parameters be the same is…not really desirable. Your struct B only has one generic parameter, so it should not use variadic generics at all. If it needs a generic multiplicity parameter as well, then I recommend heading over to the ~~Generics~~ Vector Manifesto thread.

DevAndArtist · February 21, 2019, 4:46pm

Quite interesting idea you have here. Just thinking out loud my thoughts that something similar could be used on types to express a fixed length of variadic parameters. struct Tuple<T[1...]> or struct W<T[2 ..< 6]> (a range expression to statically define the minimum and maximum bound of parameters).

You meant Vector not Generics.

David_Sweeris · February 22, 2019, 5:46pm

I don't know if things have changed in the he intervening year and a half, but back in Nov of 2017 @John_McCall made a couple of posts that partially answers your questions. They're both from the same thread so the forum software names them the same, but these two links really are different

Synthesizing Equatable, Hashable, and Comparable for tuple types - #63 by John_McCall
Synthesizing Equatable, Hashable, and Comparable for tuple types - #65 by John_McCall

Assuming nothing has changed WRT this in the past year and a half, the notable quote relevant to this thread is, "I think it would be difficult to allow useful user-defined extensions/conformances of arbitrary tuple types without variadic generics". I'd love to know if he (or anyone else who's sufficiently familiar with the compiler) thinks this is still the case.

IIRC @Douglas_Gregor is (or at least was at one point) the generics guy, so maybe he has thoughts on the matter as well.

John_McCall · February 22, 2019, 6:06pm

Nothing has changed (or will change) about that assessment: any mechanism that makes it possible to do non-trivial user-defined extensions of arbitrary tuples is essentially providing some sort of variadic generics.

Slava_Pestov · February 22, 2019, 6:46pm

Do you think it would be worthwhile at some point to have the compiler and runtime provide special-case support making tuples equatable and hashable but nothing user-defined?

anandabits · February 22, 2019, 6:47pm

If this was feasible it would be pretty awesome to have. I have a custom Unit type for the sole reason that Void is not Equatable and Hashable and would love to ditch it.

taylorswift · February 22, 2019, 6:49pm

i suspect Hashable and Equatable form 95% of the use cases for this feature, and tuple-based vector libraries make up the other 5%

Slava_Pestov · February 22, 2019, 6:50pm

One truly horrible workaround would be an untyped AnyTuple wrapper type that conforms to Hashable and contains a tuple, implementing equality and hashing via reflection on the underlying tuple value.

John_McCall · February 22, 2019, 6:53pm

Yes, I think it would be useful to provide special-case conformances for tuple equatability and hashability. We could certainly just generate them magically in the runtime, although I think we'd almost certainly want to also allow devirt/specialization/inlining at the SIL level.

David_Sweeris · February 22, 2019, 7:57pm

Codable would also be nice, but I'm not sure if that could work for Tuples with unnamed elements.

Karl · February 23, 2019, 11:20am

Don’t forget metatypes, please! :)

anandabits · February 23, 2019, 2:36pm

Metatypes aren’t structural types. Static members on the underlying type are actually instance members on the metatype so you can extend them today, you just can’t conform them to protocols. I have some notes on a related pitch / manifesto I plan to present when I have a chance. The design I have in mind would allow metatypes (and existentials) to conform to protocols.

Genaro-Chris · February 23, 2019, 9:51pm

If this manifesto of yours supports extension of metatypes, then I really think now will be the best time to present it. So by the time or before Swift 6.0 is out, extension of metatypes are implemented.

anandabits · February 24, 2019, 12:39am

I’ll try to post something in the next month or two, but that won’t determine whether anything makes it into Swift 6 or not. That requires implementation and I won’t be able to do that. But it’s always possible somebody will be interested in collaborating as an implementer.

yxckjhasdkjh · February 25, 2019, 1:40pm

Correct me if I'm wrong, but isn't this mostly a problem because of the "arbitrary tuples" requirement? I mean, isn't it reasonable to say that if you use a 25 element tuple you're probably doing something wrong? Seems to me that even just being able to add protocol conformances to fixed size tuples would be a massive improvement, even if it does potentially mean that there is some code duplication. To some extent that kind of code duplication can also be mitigated by using something like sourcery.

John_McCall · February 25, 2019, 6:50pm

Yes, it would be comparatively easy to allow extensions on just pairs or triples, although doing that in the short term might interfere with a variadic extension that provided the same conformances in the long term.

Jon_Hull · February 26, 2019, 3:40am

On the prefix vs postfix argument to represent variatic tuples, how about:

(T, ...)

David_Sweeris · February 27, 2019, 12:11am

Are you suggesting that for heterogeneous or homogeneous tuples?