Allow static extensions of generic types to be written without where clauses

the syntax itself does not depend on that particular feature

Yes, that's true. I will, but I would like to first ask whether someone is already working on this. @Slava_Pestov @huon do you have any information on this?

1 Like

There is the potential for confusion between referring to an existing type and declaring a new generic parameter (people already accidentally shadow generic parameters of a type with generic parameters of methods all the time) so care has to be taken here. And while this doesn't depend on parameterised extensions being implemented, if that is a likely feature then the syntax for the two will need to interact in an understandable way. Taking one possible example syntax for parameterised extensions from the manifesto:

extension<T> Array { … }
extension Array<U> { … }
extension<T> Array<U> { … }

could be confusing if T and U are a combination of a new generic parameter and an existing type. Since the proposed syntax is shorthand for something that is already possible, it might be better to wait for a more complete picture before implementing it.

I don't see anything confusing enough to be concerned about – the first one is a generic parameter on the extension, the second one is a concrete subtype of a generic type. For me, it is as 'confusing' as class Derived<T>: Base<Int> {...} might seem to someone.

1 Like

I have a concern. When the generic argument is a class, you can currently have two distinct extensions:

// Base and its subclasses
extension Foo where T: Base { ... }

// Base only
extension Foo where T == Base { ... }

What would extension Foo<Base> mean? What would be the syntax for the other one, then?

Sure, that's a valid opinion. if we knew concretely what the syntax for all planned generics features would be then there could be a discussion about if combinations were confusing or not. But that was just the example from the manifesto, and my wider point was that we don't know what the syntax or supported features will be, so care has to be taken, particularly for shorthand syntax that doesn't add new capabilities.

What would extension Foo<Base> mean?

Of course, T == Base. The syntax for the other one is the usual generic way: T where T is a subclass of
Base.
@gwendal.roue These are established and very natural rules. In the case of functions,

func foo<T>(_ arg: Foo<T>) where T == Base
func foo<T>(_ arg: Foo<T>) where T: Base

The first one is, in contrast to the second, I hope understadably, equivalent to func foo(_ arg: Foo<Base>)

1 Like

That "of course" is quite quick!

But I least I understand that the convenience syntax is not supposed to replace the current one: there will be a way out of the default.

My though is that if swift is ever going to support protocols as concrete types (allowing for example Array<SomeProtocol> to be a valid type) then we need to use both the where T == Base and where T: Base depending on the context.

If it is a "non-inheritable" type such as a struct or enum, it uses the where T == Base syntax because that is what it has to be. When you use a protocol or class it uses where T: Base. Otherwise you end up where anything that has "inherited" a protocol can use the extension while subclasses can't which would be inconsistent.

Sorry, I am really tired and my brain isn't working and for some reason I was thinking that where T == Base worked only with Base not subclasses of Base.

Can you explain what is meant by "we need to use both depending on the context"?
I'm not sure if this brings clarity, but a same-type requirement and a subtype requirement are different things that have never had any problems in coexisting in the language. A generic entity that has a same-type requirement can't be used on anything other than that very type, while a subtype requirement makes it possible to use the entity on any subclass and the class itself. When it comes to whether you can cast generic types (i.e. Foo<Derived> as Foo<Base>) to be able to use some functionality that is under a same-type constraint, it is more about variance of generic types than syntax or types of constraints.

I don‘t understand the issue being raised here. There is literly no question about whether it should be : or ==. The manifesto explicitly mentions the answer to that already:

Note that when one is extending nominal types, we could simplify the syntax somewhat to make the same-type constraint implicit in the syntax [...]

The new syntax is not meant to replace anything, it‘s a convenience alternative, if you don‘t like it you don‘t have to use it and can stick to the where clause which still allows you to express : when required.

While I can fully appreciate why the proposed syntax must mean == and not :, the fact is that based on the reactions here from people very experienced in Swift, there is a question as to its meaning. This suggests that, should this idea be implemented, other users will have the same confusion.

It's not a matter of "if you don't like it you don't have to use it" because code is read more often than it is written. If even experienced users can misinterpret this shorthand, then we must give consideration as to whether its inclusion in the language will do more harm than good, especially here where misinterpreting == to mean : can lead to subtle errors.

1 Like

I've edited my message because I'm really tired and my brain wasn't working 100% when I wrote that post. Sorry for adding confusion.

While you are right in what you said, I still don‘t understand how experienced and even new swift developers can misinterpret the same-type-constraint. I‘d really appreaciate if you can help me to understand it.

// this seems already trivial, no?
_ = Array<Int>()

// what is the isse with this shortcut then?
extension Array<Int> { ... }

Int has no subtypes (yet), so that's obviously not an issue in your example. However, consider the "obvious" (and wrong) way of writing an extension for an array of things that conform to P:

protocol P { }
extension Array<P> { /* ... */ }

T == Base literally means that T has to be exactly Base. Whether you can cast Foo<Derived> to Foo<Base> explicitly or implicitly to use some functionality depends on the variance of the generic type.

To illustrate:

class A {}
class B: A {}

class Foo<T> {}
extension Foo where T == A {
  func foo() {}
}

Foo<B>().foo() //  error: 'Foo<B>' is not a subtype of 'Foo<A>'

// because Foo isn't covariant

Well the mental model today is that protocols do not conform to themselfs which we keep repeating over and over again. It‘s not clear if that behavior will ever change but I see what you meant there. Furthermore the whole example that uses an Array to showcase the confusion is a little bit wanky since there is collection related covariance involved which for some reason creates a collision with this syntax. (IIRC there was some talk about explicitly marking generic type to make them covariant, maybe we need to settle down that topic first?)

I understand the point, but considering the source of the 'confusion' is... all over the place in Swift generics, it's really unexpected if what you say is true and the participants of this thread are by far not the only ones who will find this confusing. I guess we need to wait for more feedback.

1 Like

Thanks for understanding there is an ergonomics question as soon as classes and protocols are involved.

Well I get your point here, but I‘m sure that we cannot solve the problem with the same syntax since those constraints are still distinct and something like value subtyping or self-conforming protocols still can be introduced in the future which would break everything if the shortcut syntax had merged rules for : and ==.

The following is bikeshedding that explicitly annotates the requirement of : but it‘s a little bit terse:

extension Array<:UIView> { ... } // noticed the colon before the class?!

And please note that such syntax would prevent us to add labels for generic parameters, which makes it a really a no-go, but again it‘s bikeshedding only.

Looks good to me.

Terms of Service

Privacy Policy

Cookie Policy