I’d like to revive this idea I posted long time ago. There is only one thing I need to update here:
protocol MagicType: class /* missed the class constraint */ {
final var foo: Int { get }
final func boo()
}
What do you guys think? Is there any technical reason why this is not possible?
···
--
Adrian Zubarev
Sent with Airmail
Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:
Hello there,
I wonder if it is a good idea to be able to finalize in protocols and default implementations.
/* this should raise an error, because the class B shouldn't */
/* be able to override that function from SomeType */
func foo() {
// do something else
}
}
How do you anticipate this would interact with retroactive modeling of types which would conform the requirements of `SomeType` but also happen to have a `foo` method?
···
On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
Putting “final” on a default method implementation that is inside of a protocol extension could maybe make some sense to prevent other implementations of that method, but final in the protocol itself doesn’t make sense to me.
l8r
Sean
···
On May 18, 2016, at 2:18 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
Adrian, what would be the meaning of this final declaration? In my
understanding, a final means there can be no more overrides of that
method but there are no implementations in a protocol so I really
don't understand this use.
On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote:
On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org> wrote:
I’d like to revive this idea I posted long time ago. There is only one thing
I need to update here:
protocol MagicType: class /* missed the class constraint */ {
final var foo: Int { get }
final func boo()
}
What benefit is there in defining a protocol requirement as final?
What do you guys think? Is there any technical reason why this is not
possible?
--
Adrian Zubarev
Sent with Airmail
Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
(adrian.zubarev@devandartist.com) schrieb:
Hello there,
I wonder if it is a good idea to be able to finalize in protocols and
default implementations.
/* this should raise an error, because the class B shouldn't */
/* be able to override that function from SomeType */
func foo() {
// do something else
}
}
How do you anticipate this would interact with retroactive modeling of types
which would conform the requirements of `SomeType` but also happen to have a
`foo` method?
Putting “final” on a default method implementation that is inside of a protocol extension could maybe make some sense to prevent other implementations of that method, but final in the protocol itself doesn’t make sense to me.
It makes sense until you consider retroactive modeling. When you do that it becomes unclear whether the two are compatible and retroactive modeling is far more important.
···
On May 18, 2016, at 2:21 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
l8r
Sean
On May 18, 2016, at 2:18 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
Adrian, what would be the meaning of this final declaration? In my
understanding, a final means there can be no more overrides of that
method but there are no implementations in a protocol so I really
don't understand this use.
On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote:
On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org> wrote:
I’d like to revive this idea I posted long time ago. There is only one thing
I need to update here:
protocol MagicType: class /* missed the class constraint */ {
final var foo: Int { get }
final func boo()
}
What benefit is there in defining a protocol requirement as final?
What do you guys think? Is there any technical reason why this is not
possible?
--
Adrian Zubarev
Sent with Airmail
Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
(adrian.zubarev@devandartist.com) schrieb:
Hello there,
I wonder if it is a good idea to be able to finalize in protocols and
default implementations.
/* this should raise an error, because the class B shouldn't */
/* be able to override that function from SomeType */
func foo() {
// do something else
}
}
How do you anticipate this would interact with retroactive modeling of types
which would conform the requirements of `SomeType` but also happen to have a
`foo` method?
Adrian, what would be the meaning of this final declaration? In my
understanding, a final means there can be no more overrides of that
method but there are no implementations in a protocol so I really
don't understand this use.
···
On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote:
I’d like to revive this idea I posted long time ago. There is only one thing
I need to update here:
protocol MagicType: class /* missed the class constraint */ {
final var foo: Int { get }
final func boo()
}
What benefit is there in defining a protocol requirement as final?
What do you guys think? Is there any technical reason why this is not
possible?
--
Adrian Zubarev
Sent with Airmail
Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
(adrian.zubarev@devandartist.com) schrieb:
Hello there,
I wonder if it is a good idea to be able to finalize in protocols and
default implementations.
/* this should raise an error, because the class B shouldn't */
/* be able to override that function from SomeType */
func foo() {
// do something else
}
}
How do you anticipate this would interact with retroactive modeling of types
which would conform the requirements of `SomeType` but also happen to have a
`foo` method?
Am 18. Mai 2016 bei 21:21:40, Sean Heber via swift-evolution (swift-evolution@swift.org) schrieb:
Putting “final” on a default method implementation that is inside of a protocol extension could maybe make some sense to prevent other implementations of that method, but final in the protocol itself doesn’t make sense to me.
l8r
Sean
On May 18, 2016, at 2:18 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
Adrian, what would be the meaning of this final declaration? In my
understanding, a final means there can be no more overrides of that
method but there are no implementations in a protocol so I really
don't understand this use.
On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote:
On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org> wrote:
I’d like to revive this idea I posted long time ago. There is only one thing
I need to update here:
protocol MagicType: class /* missed the class constraint */ {
final var foo: Int { get }
final func boo()
}
What benefit is there in defining a protocol requirement as final?
What do you guys think? Is there any technical reason why this is not
possible?
--
Adrian Zubarev
Sent with Airmail
Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
(adrian.zubarev@devandartist.com) schrieb:
Hello there,
I wonder if it is a good idea to be able to finalize in protocols and
default implementations.
/* this should raise an error, because the class B shouldn't */
/* be able to override that function from SomeType */
func foo() {
// do something else
}
}
How do you anticipate this would interact with retroactive modeling of types
which would conform the requirements of `SomeType` but also happen to have a
`foo` method?