[Pitch 2] Light-weight same-type requirement syntax

bzamayo · 2022-02-21T13:58:18.518Z

I feel like we are talking past each other. What I was trying to suggest was an alt-syntax that still housed the primary associated types inside the angle brackets. I thought one of your issues was that would become ambiguous if generic protocols existed in the future, so I amended by saying we could prefix the associatedtype declarations with the 'associatedtype' keyword inside the angle brackets.

So rather than (quoting your example):

protocol P<A> {
          ^~~ generic type parameter list, not primary assoc

  primary associatedtype B

  // non-primary
  associatedtype C
}

You would hypothetically declare it as

protocol P<A, associatedtype B> {

  // non-primary
  associatedtype C
}

DevAndArtist · 2022-02-21T14:08:36.965Z

Ah, that makes more sense now. While I understand what you mean, I don't think this is a good approach unless we would start explicitly annotating the primary associated types inside the declaration angle brackets today.

protocol P<associatedtype A>

Unless we come up with another short form for that, I don't think this is the syntax we all want to see as there will be several protocols with multiple primary associated types with potentially longer names.

protocol SomeProtocol<associatedtype SomeName, associatedtype SomeOtherName>

Requiring to write associatedtype before each primary associated type inside the angle brackets or just having a single associatedtype in the list feels strange to me. Also one more thing. If protocols had a generic type parameter, we may want to apply it as a default type on a potentially primary associated type.

The version with a marker seems to be more straight forward:

protocol P<A> {
  primary associatedtype B = A
}

extension SomeType: P<X> {} // SomeType.P<X>.B == X
extension SomeType: P<Y> {
  typealias P<Y>.B = Foo // default overriden 
}
exntesion SomeType: P<Z, Bar> {} // SomeType.P<Z>.B == Bar

Ben_Cohen · 2022-02-21T14:20:33.506Z

DevAndArtist:

the order of those associated types becomes important regardless
if we use a marker or shift everything into angle brakets
during the protocol declaration

Generally there is a strong expectation that declaration order inside type definitions doesn't matter. There are exceptions (like @frozen structs) but those are special cases most users aren't aware of.

This is the main reason why we don't have comparable synthesis for structs, but do for enums where ordering matters in other ways (raw values and case iteration).

On the other hand, it's well understood that the order of the generic placeholders on a type has meaning, and this understanding should transfer directly to primary associated types.

DevAndArtist · 2022-02-21T14:31:39.143Z

Wouldn't that still apply to my suggestion though? We can document and teach that the order of primary associated type exposure is reflected by their top down declaration order on the sugared use-side?

// proposed
protocol DictionaryProtocol<Key: Hashable, Value> {
  ...
}

// my suggestion that might be less discoverable at a glance
// but it keeps some known syntax integrity and future extensibility intact 
protocol DictionaryProtocol {
  // declaration order for `primary associatedtype` needs to be documented
  // as it becomes important, however it's only important for the 
  // sugared use-side only
  primary associatedtype Key: Hashable
  primary associatedtype Value  
  ...
}

// nothing changes for the use-side
some DictionaryProtocol<SomeKey, SomeValue>

It does feel like the primary markers would only enable a few compiler checks:

if there is a primary marker, allow the sugared syntax P<Something>
link the order from the generic type parameter list with every primary associated types in their restrictive order

By the end of the day, we're talking only about sugar syntax for a same-type constraint. The general feature as John previously mentioned still does not rely on any kind of order of associated types (primary or not).

Ben_Cohen · 2022-02-21T14:40:13.027Z

DevAndArtist:

We can document and teach that the order of primary associated type exposure is reflected by their top down declaration order

Sure, we can document anything and hope people read the docs. But should tread carefully where a design violates a usually-safe assumption that you can reorder declarations. Reorganization of source code is a common thing to do and this would introduce a new way in which doing so could break code. @frozen is an exception to this because that is a "user beware" feature for when you are intentionally making your ABI fragile to gain performance. This feature is not like that.

gwendal.roue · 2022-02-21T14:47:59.887Z

Considering the difficult migration for libraries (refs 1, 2), keeping @_primaryAssociatedType in one form or another would help (and then order would matter, yes, and this would be very clearly understood):

// New syntax
protocol MySequence<Element> { }
protocol DictionaryProtocol<Key: Hashable, Element> { }

// Alternative syntax for libraries with compatibility constraints
protocol MySequence {
  #if compiler(>=...)
  @primaryAssociatedType associatedtype Element
  #else
  associatedtype Element
  #endif
}

protocol DictionaryProtocol {
  #if compiler(>=...)
  // Order matters: deal with it
  @primaryAssociatedType associatedtype Key: Hashable
  @primaryAssociatedType associatedtype Element
  #else
  associatedtype Key: Hashable
  associatedtype Element
  #endif
}

The acceptance notes for SE-0035 (Introduce existential any) has postponed the discussion about the transition path. Maybe the transition path for this pitch will be postponed as well. But postponing does not mean ignoring, right?

And if each transition path needs its own pitch and proposal, well this puts the transition path in great danger, since very few people understand the need for those transition paths, and among them even less have the ability and time to complete a proposal and its implementation.

DevAndArtist · 2022-02-21T14:49:20.366Z

While I understand your point, I would like to throw the question into the room if reorganizing associated types vertically inside an evolving protocol is really a concern that we should solve in a way that does not require documenting the 'sugared' call-side order? Does that concern really outweigh the trade-off for keeping syntactical spare space for another possible feature?

// proposed syntax
protocol P<A, B> { ... }
// yes it's probably unlikely that someone updates this to
protocol P<B, A> { ... }

// my suggestion
protocol P {
  primary associatedtype A
  primary associatedtype B
}

// possible:
// * but is that really that likely to happen without being caught very quickly?
// * does this really needs to be solved differently especially with such trade-offs?
protocol P {
  primary associatedtype B
  primary associatedtype A
}

Again, we're talking about sugar code for a non-existing general feature. If that existed, here's what the above concerns could potentially look like:

// the non-sugared general feature does not have this issue
func foo() -> <T: P> T where T.A == ConcreteA, T.B == ConcreteB

// only the sugar version from the current proposal has the order issue
func foo() -> some P<ConcreteA, ConcreteB>

// if someone was to re-order `primary associatedtpe A` and `primary associatedtype B`
// this will likely instantly break and `ConcreteA` will land in `B`, while `ConcreteB` will become `A`
// 👆is that such a big deal?

In that spirit: Does solving the 'order' problem for sugar syntax justifies burning an entire different future feature, which then would possibly require some unusual workaround syntax? (I'm talking about the pitched alternative syntax for generic protocols in this thread protocol Q(...) {}.)

Michael_Ilseman · 2022-02-21T15:29:00.000Z

DevAndArtist:

I strongly remain in the position that the <...> should be preserved for parameterized protocols

Could you define what you mean by "parameterized protocols" or link to a definition elsewhere? I keep seeing it thrown around without any clear direction on what it actually means. For example, is the type relationship parametric or ad-hoc? If the latter, why are we so fixated on using parametric syntax?

Jumhyn · 2022-02-21T15:29:22.033Z

xwu:

I was very concerned with the use of <…> in the first version of this pitch because I was of the same opinion. However, as I said before, I am much happier with this iteration precisely because it doesn’t go half way.

Just going to throw a +1 on this. A big part of my support for the angle bracket syntax at the point of use is thanks to the alignment with the syntax at the point of definition. I would consider it a pretty big detriment if the 'compromise' position broke this alignment.

DevAndArtist · 2022-02-21T15:34:03.353Z

The context in which I used 'parameterized protocols' was to refer to 'generic protocols' as per this description:

github.com

apple/swift/blob/main/docs/GenericsManifesto.md#generic-protocols

(Source: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html, authored by Douglas Gregor)

## Introduction

The "Complete Generics" goal for Swift 3 has been fairly ill-defined thus far, with just this short blurb in the list of goals:

> *Complete generics*: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI.

This message expands upon the notion of "completing generics". It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler and the standard library. I hope to achieve several things:

* **Communicate a vision for Swift generics**, building on the [original generics design document](https://github.com/apple/swift/blob/main/docs/Generics.rst), so we have something concrete and comprehensive to discuss.

* **Establish some terminology** that the Swift developers have been using for these features, so our discussions can be more productive ("oh, you're proposing what we refer to as 'conditional conformances'; go look over at this thread").

* **Engage more of the community in discussions** of specific generics features, so we can coalesce around designs for public review. And maybe even get some of them implemented.

A message like this can easily turn into a [centithread](http://www.urbandictionary.com/define.php?term=centithread). To separate concerns in our discussion, I ask that replies to this specific thread be limited to discussions of the vision as a whole: how the pieces fit together, what pieces are missing, whether this is the right long-term vision for Swift, and so on. For discussions of specific language features, e.g., to work out the syntax and semantics of conditional conformances or discuss the implementation in compiler or use in the standard library, please start a new thread based on the feature names I'm using.

This message covers a lot of ground; I've attempted a rough categorization of the various features, and kept the descriptions brief to limit the overall length. Most of these aren't my ideas, and any syntax I'm providing is simply a way to express these ideas in code and is subject to change. Not all of these features will happen, either soon or ever, but they are intended to be a fairly complete whole that should mesh together. I've put a * next to features that I think are important in the nearer term vs. being interesting "some day". Mostly, the *'s reflect features that will have a significant impact on the Swift standard library's design and implementation.

This file has been truncated. show original

regexident · 2022-02-21T15:34:47.450Z

I gave a thorough overview of what "parameterized/generic protocols" are and why they are desirable (i.e how they fill a large gap found in Swift today) in an earlier comment to this thread.

[Pitch 2] Light-weight same-type requirement syntax Pitches

I'm still convinced that this feature is both bad syntax, as well as semantics-wise, due to conflating two orthogonal concepts (generic parameters and associated types) into one syntax: -1
Previous comments
I can't comment on how feasible generic protocols would be to implement in Swift, but as an avid user of generic traits in Rust I can at least try to give some context as to why one would want them (or something equivalent) in Swift: It's fairly long, so folding it:
Type-safe, compiler-c…

jayton · 2022-02-21T15:37:47.892Z

DevAndArtist:

I strongly remain in the position that the <...> should be preserved for parameterized protocols as described in the generics menefesto.

This is a very selective framing. Let’s review what the manifesto actually says:

Unlikely

Features in this category have been requested at various times, but they don't fit well with Swift's generics system [...]

Generic protocols

One of the most commonly requested features is the ability to parameterize protocols themselves. For example, a protocol that indicates that the Self type can be constructed from some specified type T:
protocol ConstructibleFromValue<T> {
  init(_ value: T)
}
[...]

Most of the requests for this feature actually want a different feature. They tend to use a parameterized Sequence as an example, e.g.,
protocol Sequence<Element> { ... }

func foo(strings: Sequence<String>) {  /// works on any sequence containing Strings
  // ...
}
The actual requested feature here is the ability to say "Any type that conforms to Sequence whose Element type is String"

The pitched feature directly addresses what the manifesto identifies as the most common desired use case for P<T> syntax, albeit in a slightly different way than envisioned (the manifesto prefers generalized existentials). The manifesto is quite clear in preferring this direction over parameterized protocols.

Also, as far as I can recall, nobody has yet shown an example of a “generic protocol” where parameterized protocol syntax is manifestly better than the mooted “multi-self protocol” concept. (And yes, I did just review @regexident’s examples.)

ksluder · 2022-02-21T15:39:29.961Z

The common example of a generic protocol is something like Rust’s From<T>, which has been referenced several times in this and other threads. I gave an illustration of what such a type might look like in a Swift with generic protocols in an earlier post in this thread.

ksluder · 2022-02-21T15:41:46.307Z

jayton:

Also, as far as I can recall, nobody has yet shown an example of a “generic protocol” where parameterized protocol syntax is manifestly better than the mooted “multi-self protocol” concept. (And yes, I did just review @regexident’s examples.)

On the contrary, I haven’t seen a strong defense of the assertion that generic protocols are inferior to or necessitate multi-Self protocols. I challenged this earlier but was ignored.

jayton · 2022-02-21T15:45:03.074Z

That’s an artificially high standard. If cases like constraining collections are indeed far more common, which seems highly likely, multi-Self protocols don’t need to be better than parameterized protocols, they merely need to be good enough.

ksluder · 2022-02-21T16:46:28.366Z

On the contrary, introducing the topic of multi-Self protocols has created an impossibly high standard for proponents of generic protocols. Instead of simply explaining their utility, perhaps by way of comparison to Rust which already has them, they are now forced to defend the introduction of an esoteric rank-N type class systems—one that, again, Rust is able to hide from the language user.

hisekaldma · 2022-02-21T17:05:51.299Z

Ben_Cohen:

One way to spot these is that they almost always match the generic placeholders for the concrete implementations.

This made things click for me. I wonder if this association could be made clearer somehow, maybe through naming. I don’t feel like "primary associated type" really captures this notion.

John_McCall · 2022-02-21T17:32:07.449Z

There is zero interest on the Core Team in reserving P<Int> for “generic protocols”. I can say that with confidence because we’ve had multiple conversations about it. To give you an idea of the tenor of those discussions, they’ve all turned into discussions about whether it’s acceptable Evolution procedure to just rule something out by fiat or if we formally need to go through the proposal process for a negative feature.

Arguments against using this syntax include:

There are other reasonable and available spellings for that concept if we decide we want it, such as (T,U) : Convertible. Thus we’re not talking about ruling the feature out completely; we’re talking about the practical consequences of using this particular spelling.
The generic spelling inappropriately elevates one parameter over the other when in fact there’s no relationship.
The second parameter would behave unlike an ordinary associated type, so it ought to be declared differently, and it certainly needs to be used differently. For example, since there is no functional dependency, Self has no unique member of that name. Using member syntax to declare the “associated type” would be misleading. Using member syntax to name it would immediately break down in any context where multiple conformances are known.
The generic spelling is familiar and widely used, and it would induce programmers to use the feature when in fact they ought to have a functional dependency, as they would with an ordinary protocol.

Additionally, aside from the syntax, there are fundamental soundness problems with the feature in terms of the type-level computation it accidentally enables. It’s roughly analogous to an automaton going from one stack to two. If memory serves, folks in the Haskell world were exploring the research potential and expressive power of lifting some of the restrictions on type class instances when suddenly they realized that everything they were doing was already enabled by multi-parameter type classes, just with less convenient syntax. So it’s not something we should do casually.

hborla · 2022-02-21T17:46:56.739Z

hisekaldma:

This made things click for me. I wonder if this association could be made clearer somehow, maybe through naming. I don’t feel like "primary associated type" really captures this notion.

We can certainly include a more conceptual definition of "primary associated type" in the proposal to capture this phenomenon with conforming types. As far as the terminology itself, I don't think any of us proposal authors have been able to come up with a better name for the concept, but we'd welcome other suggestions!

ksluder · 2022-02-21T17:48:09.580Z

John_McCall:

The generic spelling inappropriately elevates one parameter over the other when in fact there’s no relationship.

Quoting myself yet again:

ksluder:

Spelling it == doesn’t avoid having to choose between func ==(lhs: A, rhs: B) and func ==(lhs: B, rhs: A) . Swift still privileges the type of the left-hand side, so you have to write definitions of both functions.

[…]

Rust doesn’t implement conversions using a trait with 2 generic parameters. It models conversions using two separate traits, From<T> and Into<T> . A single generic impl<T, U> Into<U> for T provides the Into that mirrors any user-defined impl From .

I feel like there’s a significant disconnect between what people are asking for and what the Core Team is hearing. People are asking for a language-level abstraction over writing out a bunch of (e.g.) ConvertibleFrom* types. They’re not asking for types with multiple Selfs, and I don’t think there has been a thorough argument that proves that would indeed be necessary achieve what they’re asking for.

John_McCall:

The second parameter would behave unlike an ordinary associated type and so ought to be declared and used differently.

People aren’t asking for a new kind of associated type. They are asking for a factory for protocols. In other words, they’re asking for a type constructor T -> U -> V. To substitute real names, Int -> ConstructibleFrom<T> -> ConstructibleFrom<Int>. ConstructibleFrom<Int>.Self has a dependency on ConstructibleFrom<T>, and thus transitively on T.