Hello,
While I can see the recommended change as "nice" at some level, I don't
really see much practical advantage to it. The criticism of the status quo
seems to be based around aesthetics. I think aesthetics of the current
version are fine, given you can put the attribute on the previous line,
like this:
*@discardableResult*
*public mutating func thatIsSoLongthatWeNeedToPutSomethingOnTheNextLine()
-> Bool {*
*}*
I personally find that more readable than the alternative.
Also we're not talking about whether the Bool itself is discardable. For
example, it makes no sense to write:
*let something: discardable Bool = true*
There has been some discussion of "throws" as a keyword. If anything I
think that is something that is in more need of change. I've always read it
(frustratingly) as e.g. "func throws Bool", which it doesn't, it throws an
Error.
My 2c.
- Geordie
2017-10-14 0:27 GMT+02:00 Mike Kluev via swift-evolution <
swift-evolution@swift.org>:
> On 13 October 2017 at 22:50, Jean-Daniel <mail...@xenonium.com> wrote:
>
> I mean:
>>
>> func foo() -> Int { … }
>>
>> func bar(callback: () -> discardable Int) { … }
>>
>> bar(foo) // does it warns ?
>> bar({ 3 }) // does it warns ? If it does, how to avoid it ?
>>
>
> thanks.
>
> >>> And allowing it in signature but not in lambda would be confusing.
>
> not any more confusing than it is now (allowing @discardableResult before
> function name and not allowing it before closure parameters).
>
> but, if to fix that, than could be this (orthogonal to whether it is
> "@discardableResult" or "discardable"):
>
> func foo() -> Int {}
> func bar(_ callback: () -> discardable Int) {}
>
> bar(foo) // error, type mismatch
> bar({ 3 }) // error, type mismatch
> bar({ () -> discardable Int in 3 }) // ok, types matched
>
> - and -
>
> func poo() -> discardable Int {}
> func baz(_ callback: () -> Int) {}
>
> baz(poo) // ok, types compatible
> baz({ 3 }) // ok, types matched
> baz({ () -> discardable Int in 3 }) // ok, types compatible
>
> Mike
>
>
> _______________________________________________
> 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
