No, I'm talking about the implicit discardability proposed by Brent, such
as for all Optional<@discardable T>.
He proposes that the @discardable syntax has a strong motivating advantage
because it can be extended in a way to mark _types_ so that return values
of those types are always implicitly @discardable. That is:
@discardable class A { ... }
// any return value of type A is implicitly discardable
// what happens if A : Error and I throw A?
class B : A { ... }
// is any return value of type B also implicitly discardable?
On Thu, Oct 19, 2017 at 01:02 Mike Kluev <[email protected]> wrote:
> On 19 October 2017 at 05:04, Xiaodi Wu <[email protected]> wrote:
>
>>
>> d) Does a class that override a `@discardable` type inherit that
>> annotation? If not, they it's kind of a weird exception to the inheritance
>> thing, no? If so, then we'd need a @nondiscardable annotation to do
>> type-level overrides of @discardable.
>>
>>
> the very current form of @discardableResult as a function attribute leads
> to these type of questions in the first place. if it was a type modifier -
> there would be no doubt:
>
> class A {
> func foo() -> Bool {
> ...
> }
>
> func bar() -> discardable Bool {
> ...
> }
> }
>
> class B: A {
> override func foo() -> discardable Bool { // ok, types compatible
> ...
> }
>
> override func bar() -> Bool { // error. types mismatch
> ...
> }
> }
>
> Mike
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
