> On 22 Jun 2017, at 22:28, Mike Kluev via swift-evolution
> <[email protected]> wrote:
>
> On Wed, 21 Jun 2017 15:04:46 David Moore <mooredev at me.com
> <http://me.com/>> wrote:
>
> > This would be a bit counter-intutivie in my opinion, and it’s already
> > possible
> > with the language today. First of all, structs in Swift cannot be built
> > upon.
> > Rather, I believe the intention is to use protocols for such a task. That’s
> > what
> > the new Swift String and Substring structs do. The following code example
> > demonstrates the intended behavior, without any additional language
> > improvements.
> >
> > protocol Foo {
> > func a() -> Any?
> > }
> >
> > extension Foo {
> > func a() -> Any? {
> > return nil
> > }
> > }
> >
> > struct ValueSemantics: Foo {}
> >
> > class ReferenceSemantics: Foo {}
>
> while you can use protocols, and protocol extensions specifically, to share
> implementation there are two obvious problems with this "workaround":
>
> 1) protocol extensions' based implementation is very limited as you have no
> storage around. e.g. start with a normal struct method that accesses an
> instant variable and try to refactor it into a protocol extension... in other
> words try doing anything useful other than "return nil" above, anything that
> requires instance variable access. you'll have to be creative in your
> protocol implementation, e.g. have a "var storage { get set }" as part of the
> protocol and implement that "var storage" inside your struct (and class), and
> in case of "struct" it would be strange as the struct itself is (already) the
> storage, so you would introduce another level of indirection for no good
> reason other than to satisfy this workaround, which is not nice to begin with
> and has to be thought upfront (see below)
Not sure what you mean by added indirection here, the following seems perfectly
straightforward to me:
protocol Foo {
var someValue:Int { get set }
func a() -> Any?
}
extension Foo {
func a() -> Any? { return self.someValue }
}
struct ValueSemantics:Foo { var someValue:Int }
class ReferenceSemantics:Foo {
var someValue:Int { return nil }
}
There is no added access overhead here, the only difference is that the
protocol itself leaves it up to implementations whether someValue is stored or
computed.
> 2) the proposed method works with value types that are already available
> (e.g. the OS structs or third party ones) - something you can not change but
> still want to wrap into a reference type.
This sounds to me more like delegation support that's required, which is
something that I would like to see for reducing boilerplate. But I'd prefer to
see something like:
struct Foo:SomeProtocol { var someValue:Int }
class Bar:SomeProtocol, SomeOtherProtocol {
var foo:Foo implements SomeProtocol,
SomeOtherProtocol.someMethod
// Implements all of SomeProtocol, some of
SomeOtherProtocol
}
Note that's not a specific proposal for syntax, the important point here is
that I'm explicitly linking my stored property foo to implementation of a
protocol, telling the compiler to automatically use foo's properties/methods to
conform to SomeProtocol by default (but leaving me free to customise).
I don't think that masking the behaviour behind something that looks like
extension is a good idea, for this reason I prefer explicit delegation. But
like I say, I'm not 100% on my preferred syntax for it, I just think it should
be its own, distinct feature rather than potentially fooling people into
thinking they're extending a struct._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
