Re: [swift-evolution] Optional assignment operator
I ended up creating a ??= operator about a month ago to do something very
similar. It’s a shame it won’t be made part of the official library.
Although, it is very easy to add.
Just like the ?? operator the default value is only evaluated if the optional
in nil. However, unlike ?? it will
change the optional to be equal to the value on the right, iff the optional was
nil.
infix operator ??= {
associativity right
precedence 90
assignment
}
public func ??=(inout optional: VALUE?, @autoclosure defaultValue: ()
throws -> VALUE) rethrows -> VALUE {
if let value = optional {
return value
} else {
let value = try defaultValue()
optional = value
return value
}
}
- Tod
From:
mailto:swift-evolution-boun...@swift.org>>
on behalf of Trent Nadeau via swift-evolution
mailto:swift-evolution@swift.org>>
Reply-To: Trent Nadeau mailto:tanad...@gmail.com>>
Date: Thursday, May 12, 2016 at 10:52 AM
To: Rod Brown mailto:rodney.bro...@icloud.com>>
Cc: Douglas Gregor via swift-evolution
mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] Optional assignment operator
This same operator (except spelled as ??=) was up as a proposal and rejected in
February. See http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.
On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution
mailto:swift-evolution@swift.org>> wrote:
I’m tentatively supportive of this proposal. I definitely see the use case
(assign only if not not nil). Interested to hear the opinions of others here :)
-Rod
> On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via
> swift-evolution mailto:swift-evolution@swift.org>>
> wrote:
>
> Sorry if this has already been discussed, if so I couldn’t find it.
>
> I would like to propose to add to Swift an optional assignment operator ?=
> I think this would nicely align with the other uses of ?, and avoid
> repetition in this case:
>
> var value = 5
>
> var possibleNewValue: Int? = nil
>
> value = possibleNewValue ?? value
>
> It would be used like this:
>
> value ?= possibleNewValue
>
> I’ve found quite a few cases in which this would be very useful to me. It is
> already possible to implement it, but having it defined in the standard
> library would define an standard, and prevent different semantics depending
> on who implements it.
>
>
> infix operator ?= {
> associativity right
> precedence 90
> assignment
> }
>
> func ?= (inout lhs: T, rhs: T?) {
> lhs = rhs ?? lhs
> }
>
>
> Regards,
> José Manuel Sanchez
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Auto Unwrapping Of Optionals
+1 on the shadow variable idea. What an awesome idea.
- Tod
On 5/2/16, 4:41 PM, "Rod Brown" wrote:
>Wow, I'm really sad I missed this while I was writing my last response!
>
>I completely agree with this, and that is a much better solution than the ones
>previously suggested.
>
>- Rod
>
>
>> On 3 May 2016, at 6:16 AM, David Waite wrote:
>>
>> It is a bad idea to have the compiler change the interpretation of a type
>> without some hard and fast rules; the compiler’s interpretation of the
>> optionality of your code will result in your code being legal or not.
>>
>> In terms of solutions, I would prefer something similar to a guard statement
>> that, rather than exiting, shadows a constant or variable with a
>> non-optional equivalent type, e.g.
>>
>> shadow var today = today ?? NSDate()
>> let timeInterval = today.timeIntervalSinceNow
>>
>> -DW
>>
>>> On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution
>>> wrote:
>>>
>>> "I wonder if we’re pushing down the road of convenience at the expense of
>>> truth. The if/guard let syntax is clear that you’re getting a separate
>>> reference or copy, but what you’re suggesting is hiding the reality from
>>> the user for what I see as relatively little convenience."
>>>
>>> It just might be me trying to avoid using !, and especially avoid implicit
>>> unwrapped options. While there is nothing wrong with the following code it
>>> makes me very uncomfortable from a defensive programming point of view:
>>>
>>> today = today ?? NSDate()
>>> let timeInterval = today!.timeIntervalSinceNow
>>>
>>> Some developer coming along and changing the code could easily introduce a
>>> crash, such as by removing the default value. In the above example, such a
>>> change wouldn’t introduce a compiler warning/error and the bug might not
>>> reveal itself until a much later.
>>>
>>> Also using if-let or guard also doesn’t seem right, in this case, as it
>>> should never fail:
>>>
>>> today = today ?? NSDate() // self.today changed!
>>> if let today = today {
>>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>> } else {
>>> assertFailure()
>>> }
>>>
>>> Same issue with guard:
>>>
>>> today = today ?? NSDate() // self.today changed!
>>> guard let today = today else {
>>> assertFailure()
>>> return // that should never happen
>>> }
>>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>>
>>> This introduces code that just gets in the way of the code’s meaning for
>>> cases that should never happen. Yuck, there has to be a better way!
>>>
>>> - Tod
>>>
>>>
>>>
>>> From:
>>> mailto:swift-evolution-boun...@swift.org>>
>>> on behalf of Rod Brown via swift-evolution
>>> mailto:swift-evolution@swift.org>>
>>> Reply-To: Rod Brown
>>> mailto:rodney.bro...@icloud.com>>
>>> Date: Sunday, May 1, 2016 at 1:25 AM
>>> To: David Sweeris mailto:daveswee...@mac.com>>
>>> Cc: Erica Sadun via swift-evolution
>>> mailto:swift-evolution@swift.org>>
>>> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
>>>
>>>
>>> On 1 May 2016, at 3:00 PM, David Sweeris
>>> mailto:daveswee...@mac.com>> wrote:
>>>
>>> On Apr 30, 2016, at 5:42 PM, Rod Brown
>>> mailto:rodney.bro...@icloud.com>> wrote:
>>>
>>> Re-sent for Swift Evolution. Response at end.
>>>
>>> On 1 May 2016, at 6:31 AM, David Sweeris
>>> mailto:daveswee...@mac.com>> wrote:
>>> I think your idea makes a lot more sense in respect to ensuring we don't
>>> have as much magic.
>>>
>>> That said, I still wonder about the implications for thread safety etc.
>>> While it isn't a focus of Swift 3, it's something to think about whether
>>> this promotes a paradigm that cannot be supported in a threaded
>>> environment, specifically accessing properties.
>>>
>>> The if-let paradigm is a lot stronger for this set of actions. It gains a
>>> separate reference or copy to the internal value, and allows you to action
>>> it safely. Should the property change in the meantime, it isn't relevant,
>>>
Re: [swift-evolution] Auto Unwrapping Of Optionals
"I wonder if we’re pushing down the road of convenience at the expense of
truth. The if/guard let syntax is clear that you’re getting a separate
reference or copy, but what you’re suggesting is hiding the reality from the
user for what I see as relatively little convenience."
It just might be me trying to avoid using !, and especially avoid implicit
unwrapped options. While there is nothing wrong with the following code it
makes me very uncomfortable from a defensive programming point of view:
today = today ?? NSDate()
let timeInterval = today!.timeIntervalSinceNow
Some developer coming along and changing the code could easily introduce a
crash, such as by removing the default value. In the above example, such a
change wouldn’t introduce a compiler warning/error and the bug might not reveal
itself until a much later.
Also using if-let or guard also doesn’t seem right, in this case, as it should
never fail:
today = today ?? NSDate() // self.today changed!
if let today = today {
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
} else {
assertFailure()
}
Same issue with guard:
today = today ?? NSDate() // self.today changed!
guard let today = today else {
assertFailure()
return // that should never happen
}
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
This introduces code that just gets in the way of the code’s meaning for cases
that should never happen. Yuck, there has to be a better way!
- Tod
From:
mailto:swift-evolution-boun...@swift.org>>
on behalf of Rod Brown via swift-evolution
mailto:swift-evolution@swift.org>>
Reply-To: Rod Brown mailto:rodney.bro...@icloud.com>>
Date: Sunday, May 1, 2016 at 1:25 AM
To: David Sweeris mailto:daveswee...@mac.com>>
Cc: Erica Sadun via swift-evolution
mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
On 1 May 2016, at 3:00 PM, David Sweeris
mailto:daveswee...@mac.com>> wrote:
On Apr 30, 2016, at 5:42 PM, Rod Brown
mailto:rodney.bro...@icloud.com>> wrote:
Re-sent for Swift Evolution. Response at end.
On 1 May 2016, at 6:31 AM, David Sweeris
mailto:daveswee...@mac.com>> wrote:
I think your idea makes a lot more sense in respect to ensuring we don't have
as much magic.
That said, I still wonder about the implications for thread safety etc. While
it isn't a focus of Swift 3, it's something to think about whether this
promotes a paradigm that cannot be supported in a threaded environment,
specifically accessing properties.
The if-let paradigm is a lot stronger for this set of actions. It gains a
separate reference or copy to the internal value, and allows you to action it
safely. Should the property change in the meantime, it isn't relevant, because
you have you own reference/copy, and then you have the right to re-set the
property as required.
This, however, would theoretically add in an invisible ! for you. This leaves
you unable to handle the situation should the variable have been changed by
another thread between your check and your subsequent action.
Unless I'm missing something, I worry about the behaviour of such a "feature"
in a multithreaded environment. I think the previous "inout" idea actually held
a lot more weight in this regard - at least then you can act on the copy, and
have the change propagate to the main declaration, and overwrite any changes
made on another thread.
I think it would have the same resiliency as if-let, since I was envisioning
this to just be syntactic sugar for a switch statement. That is, this:
if foo is .Result { //`foo` refers to foo's associated or raw value within the
following code block
//code block
}
would get rewritten to this, for enums with associated values:
switchfoo {
case .Result(let foo): //we get a local copy of `foo` (the associated value)
for the following code block
//code block
default: break
}
or this, for enums with raw values:
switchfoo {
case .Result:
let _foo = foo.rawValue //the compiler substitutes `_foo` for `foo`
//code block
default: break
}
There’d have to be some more auto-generated code to copy assigned values back
into the original `foo`, but I don’t think it’d be hard to do.
- Dave Sweeris
Ah yes, that makes sense. So how do you see the compiler dealing with the
assignment/access problem on structs? If you assign to foo, the compiler
assigns to both “_foo” and “foo”?
I wonder if we’re pushing down the road of convenience at the expense of truth.
The if/guard let syntax is clear that you’re getting a separate reference or
copy, but what you’re suggesting is hiding the reality from the user for what I
see as relatively little convenience.
This is not to say I don’t see the problem, or the convenience… I just wonder
if this might be going a little too far.
- Rod
___
swift-evolution mailing list
swift-evolution@swift.org
https://lis
Re: [swift-evolution] Auto Unwrapping Of Optionals
Adrian, excellent example of a challenging case. I would say that when calling
any method that might mutate the value, the compiler would no longer be able to
safely auto unwrap. That really limits the usefulness of this capability, at
least for classes. For classes that would mean any call that would leave the
current context would disable the auto unwrapping. For structs, it would be any
mutating method would disable the auto unwrap.
I modified my example a bit to show how this would effect the ability to auto
unwrap.
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No !
required (auto unwrapped)
// today can no longer be auto unwrapped as calling timeIntervalSinceNow
has escaped
// the enclosing context and could cause side effects with this instance.
}
It would be nice if the compiler could know that timeIntervalSinceNow had no
dependencies or knowledge of class Test, but I doubt that would be practical.
However if Test was a struct the mutation information is readily available, so
we know these calls would be safe:
struct Test {
var today: NSDate? = nil
mutating func test() {
today = today ?? NSDate()
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow // No !
required (auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow //
Explicit unwrapping would still be allowed
print("Today is \(today)") // Would be printed as a value (not an
optional)
// today can still be auto unwrapped as it won't be mutated by
timeIntervalSinceNow or print
}
}
From:
mailto:swift-evolution-boun...@swift.org>>
on behalf of Adrian Zubarev via swift-evolution
mailto:swift-evolution@swift.org>>
Reply-To: Adrian Zubarev
mailto:adrian.zuba...@devandartist.com>>
Date: Friday, April 29, 2016 at 3:21 PM
To: "swift-evolution@swift.org<mailto:swift-evolution@swift.org>"
mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
+1 But your example is too good to be true. :)
What would happen to this code:
class A {
var value: Type? = nil
func reset() { self.value = nil }
func test() {
self.value = self.value ?? Type()
self.reset()
self.value.doSomething()
// can the compiler be sure that our value wasn't reset somewhere from
a different scope ?
}
}
I'm curious what will happen here. Can someone clarify on that?
--
Adrian Zubarev
Am 29. April 2016 um 16:37:37, Tod Cunningham via swift-evolution
(swift-evolution@swift.org<mailto:swift-evolution@swift.org>) schrieb:
I'm new to the swift evolution community, but I wanted to toss an idea out
there to get some feedback on it. So here it goes...
Currently, if you assign a non-nil value to an optional and then want to access
that optional later, in the same context, you need to manually unwrap the
value. This is usually done either by using "!" or by using something like "if
let" or guard.
What would it be like if the compiler could auto unwrap, in cases where in
knows the optional will have some value? This would make the code "clean" and
still be safe.
This concept of Auto Unwrapping of Optionals is similar to Implicitly Unwrapped
Optionals, but is only applied when the compiler knows it is safe to do so.
Take the following example:
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as an optional
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow // Requires ! or
(if let) to unwrap
// ... do stuff with timeInterval ...
}
}
With the above example, the compiler could known that today has a value after
it's set in the test method. So why couldn't the compiler auto unwrap it when
accessed? This would mean manual unwrapping would be unnecessary:
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No ! required
(auto unwrapped)
// ... do stuff with timeInterval ...
}
}
If the value later gets set to an optional value, then it will no longer be
auto unwrapable :
class Test {
var today: NSDate? = nil
func optionalDay() -> NSDate? {
return NSDate()
}
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No ! required
(auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow // Explicit
unwrapping would still be allowed
// If today is assigned an optional value, we can no longer auto unwrap i
[swift-evolution] Auto Unwrapping Of Optionals
I'm new to the swift evolution community, but I wanted to toss an idea out
there to get some feedback on it. So here it goes...
Currently, if you assign a non-nil value to an optional and then want to access
that optional later, in the same context, you need to manually unwrap the
value. This is usually done either by using "!" or by using something like "if
let" or guard.
What would it be like if the compiler could auto unwrap, in cases where in
knows the optional will have some value? This would make the code "clean" and
still be safe.
This concept of Auto Unwrapping of Optionals is similar to Implicitly Unwrapped
Optionals, but is only applied when the compiler knows it is safe to do so.
Take the following example:
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as an optional
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow //
Requires ! or (if let) to unwrap
// ... do stuff with timeInterval ...
}
}
With the above example, the compiler could known that today has a value after
it's set in the test method. So why couldn't the compiler auto unwrap it when
accessed? This would mean manual unwrapping would be unnecessary:
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an
optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No !
required (auto unwrapped)
// ... do stuff with timeInterval ...
}
}
If the value later gets set to an optional value, then it will no longer be
auto unwrapable :
class Test {
var today: NSDate? = nil
func optionalDay() -> NSDate? {
return NSDate()
}
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an
optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow// No
! required (auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow //
Explicit unwrapping would still be allowed
// If today is assigned an optional value, we can no longer auto unwrap
it
today = optionalDay()
print("Today is \(today)") // Would be printed as an optional
let timeInterval3: NSTimeInterval = today!.timeIntervalSinceNow //
manual unwrapping would be required
}
}
Note in the above example, explicit unwrapping would still be allow. The
variable is still an optional. This allows for existing code to remain
unchanged.
This change would encourage less use of forced unwrapping "!", generally
require the developer to write less code, and would maintain code safety. On
the down side, it is performing some compiler “magic”. It would be yet another
thing to explain when trying to introduce people to swift and especially
optionals.
What do you all think, would something like this be worth pursuing, what other
pluses or minus would this introduce, has something like this already been
discussed?
Thanks,
Tod Cunningham
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.
I think it would be odd and confusing to always have to use override when
implementing protocol methods (especially protocol methods without default
implementations). To me override is telling me that there is another
implementation, and I am for lack of a better word overriding that
implementation. However, for a protocol w/o a default implementation, there
is no implementation. You aren’t overriding anything. You are just conforming
to a signature. Now protocol’s with default implementations there could be a
case made for using override. Expect Swift current implementation doesn't
really override the default implementation, as shown in my example. The other
issues would be if I am overriding something, I would expect to be able to
execute the default implementation from within my override.
It might be nice to have some syntax that would identify the protocol that is
being implemented at the point of the implementation. For example (although I
don't like this syntax):
func (protocolname1, protocolname2) commonmethod() -> Void { .. the
implementation.. }
- Tod Cunningham
From: swift-evolution-boun...@swift.org on
behalf of Josh Parmenter via swift-evolution
Sent: Wednesday, April 27, 2016 8:27 PM
To: Howard Lovatt
Cc: swift-evolution
Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for
default protocol implementations.
On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution
mailto:swift-evolution@swift.org>> wrote:
I think that you should *always* have to write `override` when implementing a
protocol method, you can think of this as override an abstract declaration. In
particular I think the following should be enforced:
protocol A { func a() }
extension A { override func a() { ... } }
struct AnA: A { override func a() { ... } }
protocol B { func b() }
struct AB: B { override func b() { ... } }
I'm rather new to the list - but I would like to say that I agree with this. I
think it gives clarity both to code readability, and for learning the language.
Best
Josh
I think this change will work out well since it mimics what happened in Java,
originally the Java annotation `@Override` was used much like `override` is
currently used in Swift. However it was problematic and was changed so that you
always add the annotation, as shown above (in the Swift context). One of the
big advantages of this change is that the error messages are much better (this
was very noticeable in Java).
This proposal has come up before on swift-evolution, so it obviously has some
support.
On Thursday, 28 April 2016, Erica Sadun via swift-evolution
mailto:swift-evolution@swift.org>> wrote:
From the Swift Programming Language: Methods on a subclass that override the
superclass's implementation are marked with override-overriding a method by
accident, without override, is detected by the compiler as an error. The
compiler also detects methods with override that don't actually override any
method in the superclass.
I would like to extend this cautious approach to protocols, forcing the
developer to deliberately override an implementation that's inherited from a
protocol extension. This would prevent accidental overrides and force the user
to proactively choose to implement a version of a protocol member that already
exists in the protocol extension.
I envision this as using the same `override` keyword that's used in class based
inheritance but extend it to protocol inheritance:
protocol A {
func foo()
}
extension A {
func foo() { .. default implementation ... }
}
type B: A {
override required func foo () { ... overrides implementation ... }
}
I'd also like to bring up two related topics, although they probably should at
some point move to their own thread if they have any legs:
Related topic 1: How should a consumer handle a situation where two unrelated
protocols both require the same member and offer different default
implementations. Can they specify which implementation to accept or somehow run
both?
type B: A, C {
override required func foo() { A.foo(); C.foo() }
}
Related topic 2: How can a consumer "inherit" the behavior of the default
implementation (like calling super.foo() in classes) and then extend that
behavior further. This is a bit similar to how the initialization chaining
works. I'd like to be able to call A.foo() and then add custom follow-on
behavior rather than entirely replacing the behavior.
type B: A {
override required func foo() { A.foo(); ... my custom behavior ... }
}
cc'ing in Jordan who suggested a new thread on this and Doug, who has already
expressed some objections so I want him to have the opportunity to bring that
discussion here.
- E
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evo
Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.
Having to specify override to override the implementation of protocol leads one
further down the path that the protocol’s implementation is actually being
overridden. However, currently that is not the case. If the protocol’s
definition was actually being overridden, I think you would have a good case.
But swift, as it exists today, will still call the protocol’s default
implementation if accessed through the protocol type. So it isn’t really
overriding the implementation of the protocol:
For example:
protocol Test {
}
extension Test {
var hello: String {
return "hello"
}
}
class A: Test {
}
class B: Test {
var hello: String {
return "see ya"
}
}
print( A().hello ) // hello
print( B().hello ) // see ya
let test1: Test = A()
print( test1.hello ) // hello
let test2: Test = B()
print( test2.hello ) // hello <== not "see ya"
Thanks,
Tod Cunningham
From:
mailto:swift-evolution-boun...@swift.org>>
on behalf of Erica Sadun via swift-evolution
mailto:swift-evolution@swift.org>>
Reply-To: Erica Sadun mailto:er...@ericasadun.com>>
Date: Wednesday, April 27, 2016 at 1:10 PM
To: swift-evolution
mailto:swift-evolution@swift.org>>, Jordan Rose
mailto:jordan_r...@apple.com>>, Douglas Gregor
mailto:dgre...@apple.com>>
Subject: [swift-evolution] [Pitch] Requiring proactive overrides for default
protocol implementations.
From the Swift Programming Language: Methods on a subclass that override the
superclass’s implementation are marked with override—overriding a method by
accident, without override, is detected by the compiler as an error. The
compiler also detects methods with override that don’t actually override any
method in the superclass.
I would like to extend this cautious approach to protocols, forcing the
developer to deliberately override an implementation that’s inherited from a
protocol extension. This would prevent accidental overrides and force the user
to proactively choose to implement a version of a protocol member that already
exists in the protocol extension.
I envision this as using the same `override` keyword that’s used in class based
inheritance but extend it to protocol inheritance:
protocol A {
func foo()
}
extension A {
func foo() { .. default implementation … }
}
type B: A {
override required func foo () { … overrides implementation … }
}
I’d also like to bring up two related topics, although they probably should at
some point move to their own thread if they have any legs:
Related topic 1: How should a consumer handle a situation where two unrelated
protocols both require the same member and offer different default
implementations. Can they specify which implementation to accept or somehow run
both?
type B: A, C {
override required func foo() { A.foo(); C.foo() }
}
Related topic 2: How can a consumer “inherit” the behavior of the default
implementation (like calling super.foo() in classes) and then extend that
behavior further. This is a bit similar to how the initialization chaining
works. I’d like to be able to call A.foo() and then add custom follow-on
behavior rather than entirely replacing the behavior.
type B: A {
override required func foo() { A.foo(); … my custom behavior … }
}
cc’ing in Jordan who suggested a new thread on this and Doug, who has already
expressed some objections so I want him to have the opportunity to bring that
discussion here.
— E
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
