override-like keyword for default implementations


(Johannes Weiss) #1

Hi swift-users,

Is there anything like the `override` keyword for making sure that default implementations in protocols are not adding a new function?

An example would be the following:

    protocol FooProto {
        func foo()
    }
    
    extension FooProto {
        func foo() { /* <-- can I mark this as being a default implementation */
            print("foo default")
        }
    }

Right now, there's a `func foo()` default implementation for `FooProto` but if later of `foo` gets refactored to `bar`, we lose the default implementation which can lead to problems.

Is there anything in Swift (like the `override` keyword) that allows me to say this is a default implementation and not a new method?

Thanks,
  Johannes


(Charles Srstka) #2

Even that won’t completely solve the problem, though, because:

protocol P {
  func foo() {
    // default implementation
  }
}

struct S: P {
  func foo() {
    // overriden implementation
  }
}

If foo is refactored here, S will start getting the wrong implementation of it, silently, with no warning.

People have tried to bring up proposals to add some sort of “override”-like keyword for protocols on swift-evolution a bunch of times, but it always gets shouted down by certain members of the group, so we’re probably permanently stuck with this situation where a supposedly “protocol-oriented” language is not safe to use with protocols.

Charles

···

On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:

There is not.

At some point in the future, I believe the plan is to eventually allow default implementations to be written in-line within the protocol declaration itself. In other words, the fact that default implementations currently must appear in extensions, is a temporary limitation that has not yet been a priority to address.

Once we gain the ability to define default implementations within protocols themselves, rather than extensions, then your use-case will “just work” (at least as long as you control the protocol anyway). I wouldn’t hold my breath though, as that behavior will not appear this year, and the plans for next year have not been hashed out yet.


#3

There is not.

At some point in the future, I believe the plan is to eventually allow
default implementations to be written in-line within the protocol
declaration itself. In other words, the fact that default implementations
currently must appear in extensions, is a temporary limitation that has not
yet been a priority to address.

Once we gain the ability to define default implementations within protocols
themselves, rather than extensions, then your use-case will “just work” (at
least as long as you control the protocol anyway). I wouldn’t hold my
breath though, as that behavior will not appear this year, and the plans
for next year have not been hashed out yet.

Nevin

···

On Tue, May 16, 2017 at 11:53 AM, Johannes Weiss via swift-users < swift-users@swift.org> wrote:

Hi swift-users,

Is there anything like the `override` keyword for making sure that default
implementations in protocols are not adding a new function?

An example would be the following:

    protocol FooProto {
        func foo()
    }

    extension FooProto {
        func foo() { /* <-- can I mark this as being a default
implementation */
            print("foo default")
        }
    }

Right now, there's a `func foo()` default implementation for `FooProto`
but if later of `foo` gets refactored to `bar`, we lose the default
implementation which can lead to problems.

Is there anything in Swift (like the `override` keyword) that allows me to
say this is a default implementation and not a new method?

Thanks,
  Johannes
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Jordan Rose) #4

I object to this characterization. People have tried to bring up such proposals, and it is invariably pointed out (usually by the same group of us) that these proposals don't discuss retroactive modeling, and then the thread dies. I can't remember a case where the proposal author actually incorporates this feedback into their proposal to handle retroactive modeling, or extension members of one protocol being used as the default implementation of another protocol.

(This just means the problem space is more difficult than the proposer initially thought, and they're not going to take that on right now, which is fine. It's a learning experience; designing features that interact well with the whole language is not easy! We should probably add this to the "commonly proposed" list, though, so that we don't keep retreading that initial ground.)

Jordan

···

On May 16, 2017, at 10:44, Charles Srstka via swift-users <swift-users@swift.org> wrote:

On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

There is not.

At some point in the future, I believe the plan is to eventually allow default implementations to be written in-line within the protocol declaration itself. In other words, the fact that default implementations currently must appear in extensions, is a temporary limitation that has not yet been a priority to address.

Once we gain the ability to define default implementations within protocols themselves, rather than extensions, then your use-case will “just work” (at least as long as you control the protocol anyway). I wouldn’t hold my breath though, as that behavior will not appear this year, and the plans for next year have not been hashed out yet.

Even that won’t completely solve the problem, though, because:

protocol P {
  func foo() {
    // default implementation
  }
}

struct S: P {
  func foo() {
    // overriden implementation
  }
}

If foo is refactored here, S will start getting the wrong implementation of it, silently, with no warning.

People have tried to bring up proposals to add some sort of “override”-like keyword for protocols on swift-evolution a bunch of times, but it always gets shouted down by certain members of the group, so we’re probably permanently stuck with this situation where a supposedly “protocol-oriented” language is not safe to use with protocols.


(Slava Pestov) #5

It’s not clear if such a keyword can be designed in a way that covers all cases. For example, consider a protocol extension that provides a default implementation for a requirement in a different protocol:

protocol R {
  func f()
}

protocol P {}

extension P {
  func f()
}

struct S : R, P {}

Or a constrained extension that provides a default that only applies in certain cases:

protocol P {
  func f()
}

extension P where Self : AnyObject {
  func f()
}

class C : P {}

Slava

···

On May 16, 2017, at 8:53 AM, Johannes Weiss via swift-users <swift-users@swift.org> wrote:

Hi swift-users,

Is there anything like the `override` keyword for making sure that default implementations in protocols are not adding a new function?

An example would be the following:

   protocol FooProto {
       func foo()
   }

   extension FooProto {
       func foo() { /* <-- can I mark this as being a default implementation */
           print("foo default")
       }
   }

Right now, there's a `func foo()` default implementation for `FooProto` but if later of `foo` gets refactored to `bar`, we lose the default implementation which can lead to problems.

Is there anything in Swift (like the `override` keyword) that allows me to say this is a default implementation and not a new method?

Thanks,
Johannes
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Charles Srstka) #6

I object to this characterization. People have tried to bring up such proposals, and it is invariably pointed out (usually by the same group of us) that these proposals don't discuss retroactive modeling, and then the thread dies. I can't remember a case where the proposal author actually incorporates this feedback into their proposal to handle retroactive modeling, or extension members of one protocol being used as the default implementation of another protocol.

(This just means the problem space is more difficult than the proposer initially thought, and they're not going to take that on right now, which is fine. It's a learning experience; designing features that interact well with the whole language is not easy! We should probably add this to the "commonly proposed" list, though, so that we don't keep retreading that initial ground.)

There have been a number of suggestions made on the list; many involve the idea of spelling retroactive conformances differently from non-retroactive ones somehow, since the two look exactly the same but really aren’t doing the same thing. Off the top of my head, I remember seeing suggestions for a “retroactive” keyword, suggestions to include the method signatures without bodies, various mapping syntaxes, etc. They don’t ever seem to get much attention or traction.

The reason it’s frustrating to me is that I spent a lot of time last year dealing with a refactor where I kept finding ‘stragglers’ at runtime, post-refactor, a situation that wouldn’t have happened if I’d used classes and inheritance. Also frustrating is the fact that it’s probably all off the table now, since any change made at this point would certainly be source-breaking.

It’s not clear if such a keyword can be designed in a way that covers all cases. For example, consider a protocol extension that provides a default implementation for a requirement in a different protocol:

protocol R {
func f()
}

protocol P {}

extension P {
func f()
}

struct S : R, P {}

Huh, I didn’t know that that would work. I’d figured that since methods in protocol extensions that aren’t in the protocol are strictly statically dispatched, they wouldn’t participate in protocol method lookup.

Anyway, my ideal would probably be to broaden the concept a bit, since most of the issue comes from the problem of knowing whether a protocol has a default implementation or not. I’d prefer to require a keyword for *all* protocol implementations:

protocol P {
  func foo()
}

struct S: P {
  implement func foo() { … } // doesn’t matter whether some extension provides foo() or not
}

I think that would take care of the issue with the constrained extension. As for retroactive, I’m pretty agnostic about how that’s handled, but I’ve seen:

protocol P {
  func foo()
}

struct S {
  func foo()
}

retroactive extension S: P {}

or:

extension S: P {
  implement func foo() // with no body
}

I remember seeing some as well that actually allowed the struct’s method to be named something other than “foo”, with a way to map “foo” to the actual method name, but I can’t remember what syntax they used.

Charles

···

On May 16, 2017, at 4:41 PM, Jordan Rose <jordan_rose@apple.com> wrote:
On May 16, 2017, at 5:05 PM, Slava Pestov via swift-users <swift-users@swift.org> wrote:


(Vladimir) #7

There is not.

At some point in the future, I believe the plan is to eventually allow default implementations to be written in-line within the protocol declaration itself. In other words, the fact that default implementations currently must appear in extensions, is a temporary limitation that has not yet been a priority to address.

Very interested, why do you have this impression? I didn't see this idea in the list previously(probably I just missed it). I strongly believe there can't be such 'plan'.

Once we gain the ability to define default implementations within protocols themselves, rather than extensions, then your use-case will “just work” (at least as long as you control the protocol anyway). I wouldn’t hold my breath though, as that behavior will not appear this year, and the plans for next year have not been hashed out yet.

Even that won’t completely solve the problem, though, because:

protocol P {
func foo() {
// default implementation
}

struct S: P {
func foo() {
// overriden implementation
}

If foo is refactored here, S will start getting the wrong implementation of it, silently, with no warning.

People have tried to bring up proposals to add some sort of “override”-like keyword for protocols on swift-evolution a bunch of times, but it always gets shouted down by certain members of the group, so we’re probably permanently stuck with this situation where a supposedly “protocol-oriented” language is not safe to use with protocols.

Exactly!
I can remember these related threads in swift-evolution:
"Requiring proactive overrides for default protocol implementations"
"Requiring special keyword to mark protocol implementation methods"

···

On 16.05.2017 20:44, Charles Srstka via swift-users wrote:

On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

Charles

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


(Howard Lovatt) #8

Here is a proposal I put forwards last month that addresses the issue (and
others), the original versions did not allow retroactive modeling but
following feedback it was incorporated.

PS Bitten by this problem two days ago, copied some example Swift 2 code
into a Swift 3 project and an obj-c method had changed its name. Took ages
to find the culprit! The error was a null pointer exception it a completely
different bit of code! Very frustrating!

···

============================================================

# Proposal: Split extension into implementing methods and adding methods
and protocols retrospectively

## Revision history

Version | Date | Comment |
---------|--------------|--------------|
Draft 1 | 11 April 2017 | Initial version |
Draft 2 | 13 April 2017 | Added support for post-hoc conformance to a

protocol - replaced static final extensions with final extensions |

Draft 3 | 17 April 2017 | Added justification section |
Draft 4 | 2 May 2017 | Allow final extensions to be public and allow

ad-hoc code reuse |

## Introduction

Currently extension methods are confusing because they have different
dispatch rules for the same calling syntax. EG:

    public protocol P {
        func mP() -> String
     }
    extension P {
        func mP() -> String { return "P.mP" }
        func mE() -> String { return "P.mE" }
    }
    struct S: P {
        func mP() -> String { return "S.mP" }
        func mE() -> String { return "S.mE" }
    }
    let s = S()
    s.mP() // S.mP as expected
    s.mE() // S.mE as expected
    let p: P = s // Note: s now typed as P
    p.mP() // S.mP as expected
    p.mE() // P.mE unexpected!

The situation with classes is even more confusing:

    class C: P { /*gets the protocol extensions*/ }
    let pC: P = C()
    pC.mP() // P.mP as expected!
    pC.mE() // P.mE as expected!
    class D: C {
        /*override not allowed!*/ func mP() -> String { return "D.mP" }
        /*override not allowed!*/ func mE() -> String { return "D.mE" }
    }
    let pD: P = D()
    pD.mP() // P.mP unexpected!
    pD.mE() // P.mE unexpected!

This proposal cures the above two problem by separating extension methods i
nto two seperate use cases: implementations for methods and adding methods
and protocols retrospectively. The proposal still retains retroactively
adding protocol conformance and ad-hoc code reuse, however these are made
easy to understand and safe.

## Implementing methods in same file as type declaration

If the extension is in the **same** file as the type declaration then its
implemented methods are dispatched using a Vtable for protocols and classes
and statically for structs and enums. EG:

File P.swift

    protocol P {
        // func m() not declared in type since it is added by the extension,
under this proposal it is an error to include a declaration in a type
**and** in an extension
    }
    extension P {
        func m() { print("P.m") } // m is added to the protocol declaration
    }

Same or another file

    struct S: P {
        override func m() { print("S.m") } // Note override required
because m already has an implementation from the extension
    }
    let p: P = S() // Note typed as P
    p.m() // Now prints S.m as expected

Extensions in the same file as the declaration can have any access, can be
final, and can have where clauses and provide inheritable implementations.
Ad-hoc code reuse is supported, in particular if a class/enum/strict
already had a method, m say, and a protocol, P say, required an m then an
extension that added P would not need to provide m (i.e. as at present).

In a protocol at present you can declare a method that is then implemented
in an extension without the use of the override keyword. This situation
only applies to protocols, for structs/enumerated/classes you cannot
declare in type and implement in an extension at all. This proposal unifies
the behaviour of protocol/struct/enum/class with extensions and also
prevents the error of a minor typo between the protocol and extension adding
two methods instead of generating an error, by requiring either:

  1. The method is only declared in the protocol and not in any extensions and
is therefore abstract
  2. The method is only in one extension and not in the protocol

A method can be abstract in one protocol and implemented in a second
protocol that extends the first.

The implementation needed to achieve this proposal for a protocol is that a
value instance typed as a protocol is copied onto the heap, a pointer to
its Vtable added, and its address passed/copied (i.e. it becomes a class
instance). No change is needed for a class instance typed as a protocol,
which unlike at present can now be passed/copied as a protocol directly.
Think of a protocol as like an abstract class; cannot be instantiated like
an abstract class and which possibly has abstract methods, but in different
in that it cannot have fields but can be multiply inherited.

Static and final methods implemented in extensions are not part of the
Vtable and are statically dispatched, i.e. no change from current Swift for
static but final now has the expected meaning for a protocol. Dispatching
for structs and classes unchanged.

## Retrospectively adding protocols and methods

A new type of extension is proposed, a `final extension`, which can be
either in or outside the file in which the protocol/struct/enum/class
declaration is in:

File P.swift

    protocol P {}
    extension P {
        func m() { print("P.m") } // m is added to the protocol declaration
    }

Same or another file

    struct S: P {} // Inherits m from the extension

In file P2.swift

    protocol P2 {
        func m2()
        func m() // Note same signature as P.m which S already implements
    }

In same or another file

    final extension S: P2 { // Note extension marked final
        // m cannot be provided because S already has a final m (the
inherited method must be final)
        func m2() { print("SP2.m2") } // Implicitly final, completes
implementation of P2
        func mE() { print("SP2.mE") } // Implicitly final, not an existing
method
    }

Which are called as any other method would be called:

    let s = S() // or S() as P2 or s: P2
    s.m() // Prints S.m
    s.m2() // Prints SP2.m2
    s.mE() // Prints SP2.mE

Notes:

  1. A method added by a `final extension`, e.g. `mE`, is implicitly final
(as the name would suggest).

  2. If the `final extension` adds a method, e.g. `mE`, that method cannot
already exist. IE a `final extension` cannot override an existing method or
implement a protocol declared method that lacks an implementation (unless
it also adds the protocol). This is retroactively adding a method. Also see
next point.

  3. If the `final extension` adds a protocol, e.g. `P2`, then it must
implement all the methods in that protocol that are not implemented, e.g.
`m2`. This is retroactively adding protocol conformance. Also see next
point.

  4. If the `final extension` adds a protocol, e.g. `P2`, then it inherits
all the methods in that protocol that are implemented, e.g. `m`. These
inherited methods must be final. This is ad-hoc code reuse of final methods
when retroactively adding protocol conformance.

Final-extensions can have `where` clauses.

The implementation for a `final extension` is always static dispatching.
That is why all methods involved in a `final extension` are final. The
compiler always knows that the method can be called statically and there is
no need for a Vtable entry for any of the methods, it is as though the
methods were declared static but with the more convenient syntax of a
normal method.

## Justification

The aim of Swift is nothing more than dominating the world. Using the
current, April 2017, https://www.tiobe.com/tiobe-index/
index of job adverts for programmers the languages that are in demand are:
Java 15.568%, C 6.966%, C++ 4.554%, C# 3.579%, Python 3.457%, PHP 3.376%,
Visual Basic .NET 3.251%, JavaScript 2.851%, Delphi/Object Pascal 2.816%,
Perl 2.413%, Ruby 2.310%, and Swift 2.287%. So Swift at 12th is doing very
well for a new language and is already above Objective-C at 14th. However
there is obviously a long way to go and the purpose of this proposal is to
help with this climb.

A characteristic of many of the languages above Swift in the Tiobe Index is
that they have major third party libraries; for some languages they are
almost defined by their third part libraries, e.g. Ruby for Rails. A major
part of this proposal is to make extensions safe when using multiple
libraries from different venders. In particular, the two forms of extensions in
this proposal can safely be exported.

As part of Swift's goal of world domination is that it is meant to be easy
to learn by a process of "successive disclosure". The current inconsistent
behaviour of protocols and extensions hinders this process and is a common
gotcha for newbies. This proposal eliminates that problem also.

Extensions are not new in languages, they are part of the .NET languages
for example. Since .NET popularised extensions they have been discussed by
other language communities, particularly Java and Scala, and in the
academic community (normally termed the Expression Problem) however they
have not proved popular because of the problems they cause. Nearly all
languages have a strong bias towards keeping the language small and simple
and trade of the advantages of a feature against the disadvantages. The
feature only makes it into the language if it offers many advantages, has
few disadvantages, and is not heavily overlapping with other features. It
is this keeping it small and simple test that extensions have failed in
other languages, in particular their behaviour is hard to predict in a
large code base with multiple third party libraries.

However, extensions are popular in Swift and this proposals makes a few
changes to them to make their behaviour predictable both in terms of third
party libraries and in terms of method dispatch when the variable is typed
as a protocol. Thereby still providing extensions including retroactive
conformance and ad-hoc code reuse, but without the problems.

## Possible future work (not part of this proposal)

This proposal will naturally allow bodies to be added to protocols directly
rather than via an extension, since under the proposal the extensionadds
the declaration to the type so it is a small step to allow the protocol
methods to have an implementation.

In an opposite sense to the above adding bodies to protocols, extensions could
be allowed to add method declarations without bodies to protocols.

The two above future work proposals, if both added, would add symmetry to
where declarations and bodies may appear for protocols.

## In summary

The proposal formalises the split use of extensions into their two uses:
implementing methods and retroactively adding protocols and methods (in
both cases including ad-hoc code reuse). The purpose of this split is to
eliminate the problems associated with exceptions that have been well
documented both with respect to Swift and other languages. Syntax is added
that clarifies their two use cases (implementing methods and retroactively
adding):

  1. The former are termed extensions and must be in the same file as the
type is declared, but can have non-final or final methods.
  2. The latter are termed final-extensions and can be in any file, however
final-extensions only have final methods.

Note the distinction between an extension in the same file and in a
separate file is consistent with the philosophy that there is special
status to the same file as proposed for private in <
http://github.com/apple/swift-evolution/blob/master/proposa
ls/0169-improve-interaction-between-private-declarations-and-extensions.md

.

============================================================

  -- Howard.

On 17 May 2017 at 07:41, Jordan Rose via swift-users <swift-users@swift.org> wrote:

On May 16, 2017, at 10:44, Charles Srstka via swift-users < > swift-users@swift.org> wrote:

On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users < > swift-users@swift.org> wrote:

There is not.

At some point in the future, I believe the plan is to eventually allow
default implementations to be written in-line within the protocol
declaration itself. In other words, the fact that default implementations
currently must appear in extensions, is a temporary limitation that has not
yet been a priority to address.

Once we gain the ability to define default implementations within
protocols themselves, rather than extensions, then your use-case will “just
work” (at least as long as you control the protocol anyway). I wouldn’t
hold my breath though, as that behavior will not appear this year, and the
plans for next year have not been hashed out yet.

Even that won’t completely solve the problem, though, because:

protocol P {
func foo() {
// default implementation
}
}

struct S: P {
func foo() {
// overriden implementation
}
}

If foo is refactored here, S will start getting the wrong implementation
of it, silently, with no warning.

People have tried to bring up proposals to add some sort of
“override”-like keyword for protocols on swift-evolution a bunch of times,
but it always gets shouted down by certain members of the group, so we’re
probably permanently stuck with this situation where a supposedly
“protocol-oriented” language is not safe to use with protocols.

I object to this characterization. People have tried to bring up such
proposals, and it is invariably pointed out (usually by the same group of
us) that these proposals don't discuss retroactive modeling, and then the
thread dies. I can't remember a case where the proposal author actually
incorporates this feedback into their proposal to handle retroactive
modeling, or extension members of one protocol being used as the default
implementation of another protocol.

(This just means the problem space is more difficult than the proposer
initially thought, and they're not going to take that on right now, which
is fine. It's a learning experience; designing features that interact well
with the whole language is not easy! We should probably add this to the
"commonly proposed" list, though, so that we don't keep retreading that
initial ground.)

Jordan

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


(Howard Lovatt) #9

In the proposal I just posted in reply to Jordan Rose all these examples
would work as expected, though the syntax and/or semantics would be
slightly different:

Example 1

In R.swift

protocol R { func f() } // f is abstract

In P.swift

protocol P {} // f cannot be in protocol and extension

extension P { func f() {... } } // f is implemented and declared to be in P

In S.swift

struct S: R, P {} // f is from P whether an instance of S is types as S, P,
or R
                          // If there was a spelling mistake for f in
either P or R it would be detected since not all methods would be
implemented

Example 2

In P.swift

protocol P {} // f cannot be in protocol and extension
extension P where Self: AnyObject { func f() {... } } // f is implemented
and declared to be in P if Self is an Object, otherwise abstract in P

In C:.swift

class C: P {} // Picks up f's implementation since Self is an object

Would this be an acceptable solution - it is minorly source breaking, but I
feel all solutions will be.

  -- Howard.

···

On 17 May 2017 at 08:05, Slava Pestov via swift-users <swift-users@swift.org > wrote:

It’s not clear if such a keyword can be designed in a way that covers all
cases. For example, consider a protocol extension that provides a default
implementation for a requirement in a different protocol:

protocol R {
  func f()
}

protocol P {}

extension P {
  func f()
}

struct S : R, P {}

Or a constrained extension that provides a default that only applies in
certain cases:

protocol P {
  func f()
}

extension P where Self : AnyObject {
  func f()
}

class C : P {}

Slava

> On May 16, 2017, at 8:53 AM, Johannes Weiss via swift-users < > swift-users@swift.org> wrote:
>
> Hi swift-users,
>
> Is there anything like the `override` keyword for making sure that
default implementations in protocols are not adding a new function?
>
> An example would be the following:
>
> protocol FooProto {
> func foo()
> }
>
> extension FooProto {
> func foo() { /* <-- can I mark this as being a default
implementation */
> print("foo default")
> }
> }
>
> Right now, there's a `func foo()` default implementation for `FooProto`
but if later of `foo` gets refactored to `bar`, we lose the default
implementation which can lead to problems.
>
> Is there anything in Swift (like the `override` keyword) that allows me
to say this is a default implementation and not a new method?
>
> Thanks,
> Johannes
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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


#10

It has come up sporadically over the years, dating back I think to the old
Dev Forums before Swift was open-sourced. Best I can find with a quick
search of the Evolution list is this message
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008509.html>
from
early 2016 where Chris Lattner wrote, “This is a desired feature, but a
surprising amount of implementation effort blocks “just doing it”.”

So my understanding is that, while it may not be plan-of-record *per se*,
it is certainly on the radar.

Nevin

···

On Tue, May 16, 2017 at 4:59 PM, Vladimir.S via swift-users < swift-users@swift.org> wrote:

On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users < > swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

There is not.

At some point in the future, I believe the plan is to eventually allow
default implementations to be written in-line within the protocol
declaration itself. In other words, the fact that default implementations
currently must appear in extensions, is a temporary limitation that has not
yet been a priority to address.

Very interested, why do you have this impression? I didn't see this idea
in the list previously(probably I just missed it). I strongly believe there
can't be such 'plan'.