Yeah, well I’m not a fan of the ‘syntactically convenience features only’ like
`!!` as well, but I wouldn’t mind having the `??` overload now.
--
Adrian Zubarev
Sent with Airmail
Am 28. Juni 2017 um 23:57:59, Jaden Geller (jaden.gel...@gmail.com) schrieb:
I realize that, which is why I’m strongly against this proposal. I could
potentially be for adding the `??` overload temporarily, but I don’t really
feel it is necessary either.
On Jun 28, 2017, at 2:55 PM, Adrian Zubarev <adrian.zuba...@devandartist.com>
wrote:
Besides all that Never as a bottom type means that you can use fatalError()
literally everywhere not only on the RHS of ??.
func foo(_: Int) {}
foo(fatalError())
That said, we can kill our application everywhere we would ever imagine,
regardless of whether there is ? or ! operator present somewhere.
--
Adrian Zubarev
Sent with Airmail
Am 28. Juni 2017 um 23:50:18, Jaden Geller via swift-evolution
(swift-evolution@swift.org) schrieb:
I’m strongly against not using the `??` operator for `x ?? fatalError()` since
that is naturally what will be possible once the `Never` type is a real bottom
type. If you want to use `!!` for the `x !! “bad things!”` convenience form, I
don’t care. But the `Never` form should definitely, definitely use `??`.
On Jun 28, 2017, at 1:30 PM, Erica Sadun via swift-evolution
<swift-evolution@swift.org> wrote:
Based on the feedback on this thread, I'm coming to the following conclusions:
`!!` sends the right semantic message. "Unwrap or die" is an unsafe operation.
It is based on `!`, the unsafe forced unwrap operator, and not on `??`, the
safe fallback nil-coalescing operator. Its symbology should therefore follow
`!` and not `?`.
The `!!` operator should follow the same semantics as
`Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:
> "The unsafelyUnwrapped property provides the same value as the forced unwrap
> operator (postfix !). However, in optimized builds (-O), no check is
> performed to ensure that the current instance actually has a value. Accessing
> this property in the case of a nil value is a serious programming error and
> could lead to undefined behavior or a runtime error."
By following `Optional.unsafelyUnwrapped`, this approach is consistent with
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
> "Logic failures are intended to be handled by fixing the code. It means
> checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`, `array[i]`, `&+`
and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like image
processing and machine learning in which overhead of those checks is not
permissible."
The right hand side should use a string (or more properly a string autoclosure)
in preference to using a `Never` bottom type or a `() -> Never` closure. A
string provides the cleanest user experience, and allows the greatest degree of
self-documentation.
- A string is cleaner and more readable to type. It respects DRY, and avoids
using *both* the operator and the call to `fatalError` or `preconditionFailure`
to signal an unsafe condition:
`let last = array.last !! “Array guaranteed non-empty" // readable`
than:
`let last = array.last !! fatalError(“Array guaranteed non-empty”) //
redundant, violates DRY`
- A string allows the operator *itself* to unsafely fail, just as the unary
version of `!` does now. It does this with additional feedback to the developer
during testing, code reading, and code maintenance. The string provides a
self-auditing in-line annotation of the reason why the forced unwrap has been
well considered, using a language construct to support this.
- A string disallows a potentially unsafe `Never` call that does not reflect a
serious programming error, for example:
let last = array.last !! f() // where func f() -> Never { while true {} }
- Although as several list members mention, a `Never` closure solution is
available today in Swift, so is the `!!` operator solution. Neither one
requires a fundamental change to the language.
- Pushing forward on this proposal does not in any way reflect on adopting the
still-desirable `Never` bottom type.
On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution
<swift-evolution@swift.org> wrote:
On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong <del...@apple.com> wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Well the main debate is that, we all want early access to a feature that will
be part of Swift as soon as `Never` becomes the bottom type. When this happens
the `??` will automatically support the pitched behavior. Until then if we all
agree that we should add it now in a way that will not break anything we can
simply add an overload to `??` as I previously showed.
I believe we should add it now, but I like the recent observation that making
?? suddenly become a potentially crashing operator violates the expectation
that ? is an indication of safety.
?? does *not* become a potentially crashing operator. The *fatalError* (or
whatever else the user chooses to put there) on the right-hand side is the
crashing operation.
On the other hand, the existing semantics of Swift are that ! is always
dangerous, so making !! be the a potentially crashing operator is much more
consistent with the language.
There is no need for `!!` because it will fade in the future. If you think of
`Never` as a bottom type now then `??` will already make total sense. The
default value for T from rhs might be T or Never.
I respectfully disagree with your absolute position on this topic. Even with
Never as a bottom type in the future, it would still be more convenient for me
to type:
let last = array.last !! “Array must be non-empty"
… than it ever would be to type:
let last = array.last ?? fatalError(“Array must be non-empty”)
There is a very high bar for additions to the standard library—a new operator
added to the language is going to be around (1) forever, or (2) indefinitely
with some migration cost to users if it's ever removed. Shaving off a few
keystrokes doesn't quite meet that bar—especially when an alternative has been
shown to work already that provides the same functionality, is more general
(not coupled to fatalError or String messages), and that fits better into
Swift's design.
To make sure I'm not being too much of a downer, I would completely support
this broader feature being implemented by that alternative: the ?? +
autoclosure () -> Never combo. Then once Never does become a true bottom type,
I believe it could be removed and the calling code would still *just work*.
Dave
@erica: the rhs argument should be called something like `noreturnOrError` and
not `defaultValue`. And we should keep in mind that when Never becomes the
bottom type we have to remove that overload from stdlib, because otherwise it
will be ambiguous.
---
On the other hand if we tackle a different operator then we should rething the
'default value operator' because the second ? signals an optional but not a
non-optional or an inplicit unwrapped operator. In that case I personally thing
?! would make more sense. Unwrap or (non-optional | IUO | trap/die)
--
Adrian Zubarev
Sent with Airmail
Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution
(swift-evolution@swift.org) schrieb:
It's hard for me to articulate, but "foo !! message" feels a little too much
like a Perl-ism for my taste. Objectively that's not a great criticism on its
own, but I just don't like the "smell" of an operator that takes a value on one
side and a string for error reporting purposes on the other. It doesn't feel
like it fits the style of Swift. I prefer a version that makes the call to
fatalError (and thus, any other non-returning handler) explicitly written out
in code.
So, if the language can already support this with ?? and autoclosure/Never as
was shown above, I'd rather see that added to the language instead of a new
operator that does the same thing (and is actually less general).
On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution
<swift-evolution@swift.org> wrote:
I feel that the !! operator would be necessary for indicating that if this
fails then something went horribly wrong somewhere and we should throw the
fatalError. This allows the inclusion of optimizations using -Ounchecked and is
clear that this is an operation that could result in a runtime error just like
force unwrapping.
If we want code clarity and uniformity, then I think !! Is much better than ??
because it goes right along with the single ! Used for force unwrapping.
However, this does depend on if the operator would be returning some kind of
error that would cause the program to exit.
I think the ?? operator should not cause a program to exit early. It goes
against optional unwrapping principles. I think code could get very confusing
if some ? would return nil/a default value, and others would be causing your
program to crash and exit. The ? operators should always be classified as safe
operations.
On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution
<swift-evolution@swift.org> wrote:
On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution
<swift-evolution@swift.org> wrote:
Count me in as a strong proponent of ?? () -> Never. We don't need to burden
the language with an extra operator just for that.
You could say the same about ??
The concern that an additional operator (and one that, IMO, fits well into
existing patterns) is so burdensome seems way overweighted in this discussion
IMO.
Adding the operator, and encouraging its use, will help foster better
understanding of optionals and legitimate use of force-unwrapping in a way that
I don’t think `?? fatalError` could.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
