Why specializing a generic function explicitly is not allowed?

Question

Created Mar ’16

Replies 1

Boosts 0

Participants 2

If there is a function like this:

func serialize<T>(continuation: GenericWithLongName<T, NSError> -> Void) -> Void

Doing this is wrong:

serialize<SomeType> { obj in ... }

Doing this is ugly:

serialize { (obj: GenericWithLongName<SomeType, NSError>) -> Void in ... }

And the workaround is:

func serialize<T>( t: T.Type, continuation: GenericWithLongName<T, NSError> -> Void ) -> Void { }
serialize(SomeType.self) { obj in ... }

I feel that workaround is not perfect. It abuses the semantic of input parameter because t is not used in runtime. It's just a hint for type inference.

And the use of SomeType.self makes it a little bit harder to read code, as the meaning of .self attribute is not so intuitive.

Since Xcode will give clear error message when specializing generic explicitly, while specializing generic for class explicitly is allowed, I think it's a designed feature. But is there any negative implication from allowing explicitly specialization?

Boost

Answer 1

jeschot OP

Mar ’16

Without the specialization the code is shorter and simpler. In most cases the T.Type can be inferred from the arguments, so this is a win.

There are more cases where T.Type cannot be inferred, for example if T is only used in the body. But these cases are rare.

My 2cts

0