New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-7818] Protocol can inherit from composition type with a superclass requirement #50354
Comments
// Protocols, generic parameters and associated types can inherit
// from subclass existentials, which are "exploded" into their
// corresponding requirements. This is the comment next to the code responsible for allowing such behavior. Is this really correct? |
Both are supposed to work, but we haven't fully implemented the proposal yet. |
Can you provide a link to the proposal? I really want to look at the motivation part. |
https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md The motivation is you want to be able to define a protocol where all conforming types are required to be subclasses of another class. |
What's wrong with the much more consistent WDYT? |
"protocol P where Self : Foo" has some bugs too. These are all related problems. I see no reason to support some variants of spelling this but not others; all of these should work:
|
I don't see a serious problem in having different ways to express things either, but the way with the composition is so inconsistent. It is literally making the protocol itself rather than |
@slavapestov If this isn't a bug then the SR is invalid. Have you assigned yourself to work on something or I can resolve it? |
This bug is useful because it's another case I need to fix (protocol inheriting from class-constrained composition). I agree that there might be stylistic reasons to prefer one or the other, but converging all of these code paths to be handed in a more uniform manner will improve quality in various ways because its a good opportunity to refactor some messy code. I'm going to leave this bug open to track the work. |
I'm sorry to bother, but I'm a bit confused: Is a protocol inheriting from class-constrained composition actually a bug or a feature? If it is a feature, where is the bug? |
I'm not sure I understand what you're trying to get at. I have various bugs assigned to me that describe various facets of the problem, namely that class-constrained protocols don't work. I'm not sure I have a specific bug for a protocol inheriting from a class-constrained composition not working, but once I fix the problems I will go through the various dupes I have and make sure all the user-provided test cases work. |
Ok, I see. I was asking because I don't see a specific bug in my report. One last thing: Is there a concrete proposal for the syntax of allowing protocols to inherit from a class-constrained composition (0156 introduces class-constrained compositions)? I want to bring up a proposal to eliminate that syntax in favor of |
I think banning the form you describe actually introduces a new special case where there was none, complicating the compiler. In fact @DougGregor wanted to go the other direction and ban 'Self : ...' requirements from appearing in a protocol where clause. My preference would be to allow both. |
I think any of the options more or less complicates the compiler to a similar degree. Eliminating any of them would need additional logic to actually keep the feature for previous versions, since we care very much about compatibility. Keeping both requires accounting for overlapping uses. The only thing that I'm not happy about is the inheritance. Even if ' |
"protocol P : Foo, Class" was actually the original proposed syntax in SE-0156, but it wasn't implemented so we emit a diagnostic. "protocol P : Foo where Self : Class" was discovered on accident by users, and it doesn't really work completely. It was an oversight that it wasn't banned. |
On master, 'protocol Foo : SomeClass' now works, and 'protocol Foo where Self : SomeClass' generates an error. |
I think we (and the current implementation) have settled by now that both |
Environment
Xcode 9.3 (9E145)
Additional Detail from JIRA
md5: d5877ab191d847e52d9c9ac98be1a4a8
Issue Description:
The following remains unnoticed by the compiler.
If I try conforming to Fooo:
The compiler will stop complaining if I inherit from A.
The text was updated successfully, but these errors were encountered: