[Pitch][Bug?] Test for Anti-Conformance During Generics

CTMacUser · July 30, 2017, 8:26pm

[Apologies if this is in Swift 4 already.]

We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.

In C++, templates can be specialized or partially specialized. Either specialization lets you define special code when the template parameters match the pattern. I realized that it can anti-match by putting your secret sauce in the general version of the template and leave the specialized version empty. But, AFAIK, we can’t specialize Swift generics (in the same way), so we’re stuck.

The change needs to be added to generic parameter conformance in parameter and where clauses. We should also support an anti-version for same-type requirements.

Now the question is what token (sequence) to use? For anti-conformance to same-type, I don’t see a reason to not use the obvious “!=“ choice. But what would be the opposite of the colon used in type/protocol matching? Would “!:” look dumb? Would we have to make sure a “T!” type expression isn’t against the “:” to prevent the parser from changing conformance to anti-conformance?

Would putting a “!” directly before the type/protocol to be matched (i.e. on the right of the colon) be better?

//=====
Grammar of a Generic Parameter Clause

generic-parameter-clause → < generic-parameter-list >
‌generic-parameter-list → generic-parameter | generic-parameter , generic-parameter-list
‌generic-parameter → type-name
‌generic-parameter → type-name : !opt type-identifier
‌generic-parameter → type-name : !opt protocol-composition-type
‌generic-where-clause → where requirement-list
‌requirement-list → requirement | requirement , requirement-list
‌requirement → conformance-requirement | same-type-requirement
‌conformance-requirement → type-identifier : !opt type-identifier
‌conformance-requirement → type-identifier : !opt protocol-composition-type
‌same-type-requirement → type-identifier == type
‌same-type-requirement → type-identifier != type
//=====

Where the fourth, fifth, ninth, and tenth productions add an optional “!”. And the last production is new (although with a misleading title).

…

Now reported at <https://bugs.swift.org/browse/SR-5588>\.

···

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

Tino · July 30, 2017, 9:03pm

[Apologies if this is in Swift 4 already.]

We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.

Why do you want that?
When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
Also:
Don't forget retroactive conformance — you can never rely on non-conformance.

bob · July 30, 2017, 9:23pm

This has come up before (aside: I can’t wait for a real forum because of exactly this; it would be great if we had a StackOverflow-like feature where the subject of your post would be searched against past threads to see if it’s a duplicate, or at least to allow you to go back and see where the conversation should pick up from) and the justification given was to resolve ambiguities arising from multiple protocol extensions each providing default implementations with the same signature, especially when the signatures use Self.

···

On Jul 30, 2017, at 5:03 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

[Apologies if this is in Swift 4 already.]

We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.

Why do you want that?
When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
Also:
Don't forget retroactive conformance — you can never rely on non-conformance.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

CTMacUser · July 30, 2017, 10:30pm

I forgot about that last part. But my idea still has merit, due to why I desired it in the first place.

The “AnyObject” protocol is marked on all class types. All class types conform to it, and it’s illegal (as I understand it) to put on a type that isn’t already a class. I have been working on a “strong type-alias” proposal, and it has a similar protocol. And I came up with ideas that depend on a type NOT being a strong type-alias. That’s what prompted the post. Note that these protocols cannot be retroactively applied, so negation has merit.

Since there’s a limited number of them, a better solution could be to add a “NeverAnObject” protocol that’s automatically slapped onto non-class types (and cannot be added onto class types). And like “AnyObject,” it can be a base protocol, but this time it forces the conforming protocol to not be for classes.

···

On Jul 30, 2017, at 5:03 PM, Tino Heth <2th@gmx.de> wrote:

[Apologies if this is in Swift 4 already.]

We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.

Why do you want that?
When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
Also:
Don't forget retroactive conformance — you can never rely on non-conformance.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

xwu · July 31, 2017, 5:19am

Daryle, this discussion has indeed taken place before. One good place to
start is the Google result for "swift evolution non-conformance".

···

On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote:

> On Jul 30, 2017, at 5:03 PM, Tino Heth <2th@gmx.de> wrote:
>
>> [Apologies if this is in Swift 4 already.]
>>
>> We can have generic parameters match a protocol. But I have an idea in
my head that involves the type NOT conforming to a protocol. I don’t think
we have a way currently to work with this.
> Why do you want that?
> When something conforms, you know that you can call the methods of the
protocol, but without conformance, you can't do anything that's not
possible using "is".
> Also:
> Don't forget retroactive conformance — you can never rely on
non-conformance.

I forgot about that last part. But my idea still has merit, due to why I
desired it in the first place.

The “AnyObject” protocol is marked on all class types. All class types
conform to it, and it’s illegal (as I understand it) to put on a type that
isn’t already a class. I have been working on a “strong type-alias”
proposal, and it has a similar protocol. And I came up with ideas that
depend on a type NOT being a strong type-alias. That’s what prompted the
post. Note that these protocols cannot be retroactively applied, so
negation has merit.

Since there’s a limited number of them, a better solution could be to add
a “NeverAnObject” protocol that’s automatically slapped onto non-class
types (and cannot be added onto class types). And like “AnyObject,” it can
be a base protocol, but this time it forces the conforming protocol to not
be for classes.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

CTMacUser · July 31, 2017, 5:33am

Daryle, this discussion has indeed taken place before. One good place to start is the Google result for "swift evolution non-conformance".

I added SR-5589, to request a counter protocol to AnyObject.

···

On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jul 30, 2017, at 5:03 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:
>
>> [Apologies if this is in Swift 4 already.]
>>
>> We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.
> Why do you want that?
> When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
> Also:
> Don't forget retroactive conformance — you can never rely on non-conformance.

I forgot about that last part. But my idea still has merit, due to why I desired it in the first place.

The “AnyObject” protocol is marked on all class types. All class types conform to it, and it’s illegal (as I understand it) to put on a type that isn’t already a class. I have been working on a “strong type-alias” proposal, and it has a similar protocol. And I came up with ideas that depend on a type NOT being a strong type-alias. That’s what prompted the post. Note that these protocols cannot be retroactively applied, so negation has merit.

Since there’s a limited number of them, a better solution could be to add a “NeverAnObject” protocol that’s automatically slapped onto non-class types (and cannot be added onto class types). And like “AnyObject,” it can be a base protocol, but this time it forces the conforming protocol to not be for classes.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

DevAndArtist · July 31, 2017, 5:46am

We had some really really long talks about that before. Search for something like `AnyValue` and `ValueSemantics`. ;)

···

--
Adrian Zubarev
Sent with Airmail

Am 31. Juli 2017 um 07:33:36, Daryle Walker via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com(mailto:xiaodi.wu@gmail.com)> wrote:
> Daryle, this discussion has indeed taken place before. One good place to start is the Google result for "swift evolution non-conformance".

I added SR-5589, to request a counter protocol to AnyObject.

> On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote:
> >
> > > On Jul 30, 2017, at 5:03 PM, Tino Heth <2th@gmx.de(mailto:2th@gmx.de)> wrote:
> > >
> > >> [Apologies if this is in Swift 4 already.]
> > >>
> > >> We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.
> > > Why do you want that?
> > > When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
> > > Also:
> > > Don't forget retroactive conformance — you can never rely on non-conformance.
> >
> > I forgot about that last part. But my idea still has merit, due to why I desired it in the first place.
> >
> > The “AnyObject” protocol is marked on all class types. All class types conform to it, and it’s illegal (as I understand it) to put on a type that isn’t already a class. I have been working on a “strong type-alias” proposal, and it has a similar protocol. And I came up with ideas that depend on a type NOT being a strong type-alias. That’s what prompted the post. Note that these protocols cannot be retroactively applied, so negation has merit.
> >
> > Since there’s a limited number of them, a better solution could be to add a “NeverAnObject” protocol that’s automatically slapped onto non-class types (and cannot be added onto class types). And like “AnyObject,” it can be a base protocol, but this time it forces the conforming protocol to not be for classes.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

CTMacUser · July 31, 2017, 5:33pm

Daryle, this discussion has indeed taken place before. One good place to start is the Google result for "swift evolution non-conformance".

I added SR-5589, to request a counter protocol to AnyObject.

Part of the response that closed this as “Won’t Do” was:

AnyObject is no longer a protocol

Then, what is it?

···

On Jul 31, 2017, at 1:33 AM, Daryle Walker <darylew@mac.com> wrote:

On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

Beta · July 31, 2017, 5:49pm

Daryle, this discussion has indeed taken place before. One good place to start is the Google result for "swift evolution non-conformance".

I added SR-5589, to request a counter protocol to AnyObject.

Part of the response that closed this as “Won’t Do” was:

AnyObject is no longer a protocol

Then, what is it?

Relevant [WIP] Remove AnyObject protocol by slavapestov · Pull Request #8749 · apple/swift · GitHub

···

On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 31, 2017, at 1:33 AM, Daryle Walker <darylew@mac.com <mailto:darylew@mac.com>> wrote:

On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

CTMacUser · July 31, 2017, 10:50pm

So… it got moved one layer down of indirection?

Hmm, what would this mean for a similar “protocol”? One that has a member attached. (My “strong type-alias” proposal has all such named types derived from an “AnyAlternative” protocol, which derives from “RawRepresentable” and adds another associated type.)

···

On Jul 31, 2017, at 1:49 PM, Robert Widmann <rwidmann@apple.com> wrote:

On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Part of the response that closed [SR-5589] as “Won’t Do” was:

AnyObject is no longer a protocol

Then, what is it?

Relevant [WIP] Remove AnyObject protocol by slavapestov · Pull Request #8749 · apple/swift · GitHub

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com