Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 30 Jun 2017, at 07:23, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution >> wrote: >> >> Using an operator to provide feedback on the context of a failed unwrap has

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution > wrote: > > Using an operator to provide feedback on the context of a failed unwrap has > become a commonly implemented approach in the Swift developer Community. What > are your thoughts about

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution > wrote: > > I started a thread earlier this week about strong type-aliases and object > aliases. Here’s a fuller proposal on object aliases. > > Feature name > Proposal: SE- > Authors: Daryle

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 29, 2017, at 7:35 PM, Yuta Koshizawa wrote: > > "In -Ounchecked builds, the optimizer may assume that this function is never > called. Failure to satisfy that assumption is a serious programming error.” > > Yes, and so the following `!!` can perform identically to

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

"In -Ounchecked builds, the optimizer may assume that this function is never called. Failure to satisfy that assumption is a serious programming error.” Yes, and so the following `!!` can perform identically to `!` in -Ounchecked builds when it is inlined. public static func !!(optional:

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 10:26 AM, rintaro ishizaki wrote: > > Does this mean it's guaranteed that Substring.hashValue is always equal to > String.hashValue? Yes. ___ swift-evolution mailing list swift-evolution@swift.org

[swift-evolution] Invariant checks on strong typedefs?

In my retype idea, you can bring back symbols from the implementation type with an "export" command. There's an "export default" command to bring back all the numbered fields of a tuple or all the cases of an enum. But what would it mean to NOT include all enum cases? One option is to ban

Re: [swift-evolution] [Pitch] Object aliases

So, what’s the difference between this and teaching Key Paths to look through tuple indices - that was the only part of your example I couldn’t directly express. ~Robert Widmann > On Jun 23, 2017, at 12:28 AM, Daryle Walker via swift-evolution > wrote: > > I

Re: [swift-evolution] [Pitch] Object aliases

This video is a nice introduction to why lenses are. It is in Haskell, yes, but I believe that you can infer everything that you need from the context provided. A Brief Introduction of the Haskell Lens Library On Wed, Jun 28, 2017 at 1:42 PM, Daryle

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Fixed. Finger slipped during spell correct and I thought I had backed up through enough items -- apparently I didn't. :( -- E > On Jun 29, 2017, at 2:29 PM, Rod Brown wrote: > > Thanks Erica. That looks great. > > As a side-note, one of the sentences in “The Black

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Thanks Erica. That looks great. As a side-note, one of the sentences in “The Black Swan Deployment” references a “Mackintosh” - I believe this was supposed to be “Hackintosh”. > On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution > wrote: > > >> On Jun

Re: [swift-evolution] [Pitch or bug?] Expanding the capability of `.` prefixed lookup

I'd be happy to see this enhancement as well. For what it's worth, a real case that I've wanted to use this for is modifying named colors, as in: `view.backgroundColor = .blue.withAlphaComponent(0.5)` Not a major inconvenience for sure, but it would be nice if this worked. Jarod On Jun 29,

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 29, 2017, at 12:23 PM, Djura Retired Hunter via swift-evolution > wrote: > > >> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution >> > ha scritto: >> >> >>> On Jun 29,

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 29 Jun 2017, at 11:18 am, Ben Cohen via swift-evolution > wrote: > > >> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> In the initial example, repeated here in largely

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

On Wed, Jun 28, 2017 at 8:49 PM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > As the screener of a non-zero number of radars resulting from unwrapped > nils, I would certainly appreciate more use of guard let x = x else { > fatalError(“explanation”) } and hope that !! would

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution > ha scritto: > > >> On Jun 29, 2017, at 9:13 AM, Dave DeLong > > wrote: >> >> My usage of “!!” generally falls in to two big buckets: >> > >

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I'm not sure those examples are what we should aim for. Generally I try to avoid force unwrapping, and specifically in these cases I belive a more reliable code would be produced without either ! or the !! operators: https://gist.github.com/ilyannn/4c5530c75293db0324a04f50ae691b2a I understand

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 2:41 PM, David Hart wrote: > > Should authors use StringProtocol or String as often as possible? Our general advice is to stick with String. Most APIs would be simpler and clearer just using String rather than being made generic (which itself can come

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 29, 2017, at 9:13 AM, Dave DeLong wrote: > > My usage of “!!” generally falls in to two big buckets: > I've incorporated all the feedback to date and updated the gist: https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Re: [swift-evolution] [Pitch or bug?] Expanding the capability of `.` prefixed lookup

> On Jun 29, 2017, at 5:19 AM, Matt Gallagher via swift-evolution > wrote: > > Super short summary: > > I think a function argument or right-hand-side expression prefixed with `.` > should allow access to *any* static member on the expected type, dropping the >

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 29, 2017, at 1:05 AM, David Hart via swift-evolution > wrote: > > I’ve taken time to digest all the messages on this discussion and would like > to summarise my point of view concerning several topics: > > Usefulness of messages > > Xiaodi seems to

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> Well, a persisted inconsistency is worse than a crash :P I still strongly disagree with this, I'm sorry. Inconsistent data is an orthogonal problem to fatal errors, and a crash is basically a middle finger to the user. > To me this !! operator does not add enough value to put it in the

[swift-evolution] [Pitch or bug?] Expanding the capability of `.` prefixed lookup

Super short summary: I think a function argument or right-hand-side expression prefixed with `.` should allow access to *any* static member on the expected type, dropping the existing limitations of this syntax. Detail: At the moment in Swift, you can use a `.` (period or dot) prefix to

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 29 Jun 2017, at 12:37, Elviro Rocca wrote: > > From the user's standpoint, a crash is the worst thing possible, and should > always be avoided. A failure doesn't need to be silent for user, the app can > still communicate that there was an error with some

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

On Thu, Jun 29, 2017 at 12:45 PM, Elviro Rocca via swift-evolution < swift-evolution@swift.org> wrote: > From the user's standpoint, a crash is the worst thing possible, and > should always be avoided. A failure doesn't need to be silent for user, the > app can still communicate that there was an

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

>From the user's standpoint, a crash is the worst thing possible, and should >always be avoided. A failure doesn't need to be silent for user, the app can >still communicate that there was an error with some kind of human readable >message, and the developer can still be informed via any

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution > wrote: > > >> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution >> ha scritto: >> >> Finally, there’s a woolier justification: there’s an often-touted

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution > ha scritto: > > Finally, there’s a woolier justification: there’s an often-touted > misconception out there that force unwraps are bad, that they were only > created to accommodate legacy

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I’ve taken time to digest all the messages on this discussion and would like to summarise my point of view concerning several topics: Usefulness of messages Xiaodi seems to question the usefulness of attaching more information to the failure case of an optional's unwrapping. To his credit, the