Re: [swift-evolution] [Pitch] `let` in protocols

I think if we start to discuss composition as part of the language, it could solve this issue. In my composition pitch I didn’t go into great detail (and nothing about properties in components at this early stage - I figured I should start simple and we can think it through further as a group), bu

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

The point of the example setup I sent, is to provide a simple method for setting and/or getting values from dictionary-like types. For example, I can create a Bond between a dictionary type of [String: Any] and a value type of Foo (some class or struct). The code I sent omits some or the more pr

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

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 adopting this widely-used operator into the standard library? guard !lastItem.isEmpty else { return } let lastItem =

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

I like this idea, but I like idea of treating `Never` as a bottom type more. This would allow other `Never`-returning functions like `preconditionFailure` to be used as well. let x = y ?? preconditonFailure("reason") This also avoids the issue of `!!` needing `file` and `line` arguments. Cheer

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

I’ve run into this issue many times in the real world as well. For example, consider the following protocol: protocol OptionalType { associatedtype Wrapped } It is not possible to conform `Optional` to this protocol because its generic type is already named `Wrapped`. Only when the associat

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

As you write, this operator becomes sugar for “?? fatalError()” once Never becomes a true bottom type. In the meantime, can’t the same thing be accomplished by overloading fatalError so it’s a generic function that returns a discardable result of type T, which in turn calls the Never-returning ove

[swift-evolution] Trying to grok the ABI documents, w.r.t. strong typedefs

I’m trying to understand two of the ABI documents, and , with respect to a strong type-alias idea I just posted: retype IDENTIFIER: IMPLEMENTATION-TYPE (“,” PROTOC

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

+1 I had a slightly different implementation. https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a // // UnwrapOrTrap.swift // infix operator ?! : NilCoalescingPrecedence /// Performs a nil-coalescing operation, returning the wrapped value of an /// `Optional` instance or uses t

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

+1 to Adrians implementation. While I like the sugar of both, I don’t think the operator should necessarily always cause a fatalError. Maybe we could use both the !! For some kind of fatal error and Adrians !? To just use @noreturn to leave the current function. > On Jun 27, 2017, at 11:29 AM,

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

I would not use it. Somehow it gives me the creeps to leave something like ‘fatalError’ in a shipping application. During development it could make sense, but then again I like to keep development and shipping the same as much as possible. Regards, Rien Site: http://balancingrock.nl Blog: http:

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

I've found a similar thing useful, but with Errors instead of fatalErroring: infix operator ?! : NilCoalescingPrecedence func ?!(lhs: T?, rhs: @autoclosure () -> Error) throws -> T { if let lhs = lhs { return lhs } throw rhs() } let x = try failableFunc() ?! MyError.somethingFailed On

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

On June 26, 2017 at 5:43:42 PM, Karl Wagner via swift-evolution (swift-evolution@swift.org) wrote: I would support a definition of encodedOffset that removed mention of UTF-16 and phrased things in terms of String.Encoding and code-units. For example, I would like to be able to construct new

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

> On Jun 27, 2017, at 12:39 PM, Jaden Geller via swift-evolution > wrote: > > I’ve run into this issue many times in the real world as well. For example, > consider the following protocol: > > protocol OptionalType { > associatedtype Wrapped > } > > It is not possible to conform `Optiona

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

Big +1. Using `!` is widely seen as a smell. However, the need for it still arises; they are preconditions, of a sort. It has become prevalent in my teams’ codebases to do “guard else preconditionFailure”. I like `!!` over something like `?!`; it follows the pattern that almost every `?` in the la

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

Also a +1 from me. This is something I always put in to my code. I agree that having `Never` as a bottom type is interesting, but even if that were the case, the proposed “!!” operator is still useful, because it short-circuits having to fatalError() myself. IE: let last = array.last ?? fatalEr

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

> it gives me the creeps to leave something like ‘fatalError’ in a shipping > application Agreed, and I would use it for _exactly_ this reason. I avoid force unwrapping in production code, looking first for ways to gracefully handle the situation. Whenever I do use !, there is careful reasoni

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

I agree with Jaden and Xiaodi above—making Never a proper bottom type and using ?? would accomplish the same thing, and it's more general because it doesn't imply fatalError. IMO, I don't think we should be making it *easier* to hide traps in our code. I don't think having to write a full guard/fa

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

> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution > wrote: > > Also a +1 from me. This is something I always put in to my code. > > I agree that having `Never` as a bottom type is interesting, but even if that > were the case, the proposed “!!” operator is still useful, because it

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

> On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution > wrote: > > I agree with Jaden and Xiaodi above—making Never a proper bottom type and > using ?? would accomplish the same thing, and it's more general because it > doesn't imply fatalError. > > IMO, I don't think we should be

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

> On Jun 27, 2017, at 2:49 PM, David Hart via swift-evolution > wrote: > > >> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Also a +1 from me. This is something I always put in to my code. >> >> I agree that having `Never` as a

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

Can’t we simply overload ?? to support @autoclosure () -> Never now and remove that overload when Never is the bottom type? Syntactically it would look and do the same. --  Adrian Zubarev Sent with Airmail Am 27. Juni 2017 um 21:52:01, Matthew Johnson via swift-evolution (swift-evolution@swi

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

> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution > wrote: > > As you write, this operator becomes sugar for “?? fatalError()” once Never > becomes a true bottom type. > > In the meantime, can’t the same thing be accomplished by overloading > fatalError so it’s a generic function

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

How about? public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> Never) rethrows -> T { switch optional { case .some(let value): return value case .none: try noreturnOrError() } } --  Adrian Zubarev Sent with Airmail Am 27. Juni 2017 um 21:54:

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

> On Jun 27, 2017, at 1:51 PM, Dave DeLong via swift-evolution > wrote: > > >> On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree with Jaden and Xiaodi above—making Never a proper bottom type and >> using ?? would accomp

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

There are a few ways in which this issue could be addressed. The first, and most desirable approach in my opinion, would be full inferencing of a given associatedtype and a generic. An example of the foregoing would be the following: protocol Foo {     associatedtype ABC } struct Bar : Foo {  

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

> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev > wrote: > > How about? > > public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> > Never) rethrows -> T { > switch optional { > case .some(let value): > return value > case .none: > try noreturnOrErr

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

This solution is nifty indeed, and has the chief advantage of working. On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 27, 2017, at 1:03 PM, Adrian Zubarev < > adrian.zuba...@devandartist.com> wrote: > > How about? > > public func ?? (opti

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

On Tue, Jun 27, 2017 at 16:44 David Moore via swift-evolution < swift-evolution@swift.org> wrote: > There are a few ways in which this issue could be addressed. The first, > and most desirable approach in my opinion, would be full inferencing of a > given associatedtype and a generic. An example o

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

on Tue Jun 27 2017, Drew Crawford wrote: > On June 26, 2017 at 5:43:42 PM, Karl Wagner via swift-evolution > (swift-evolution@swift.org) wrote: > > I would support a definition of encodedOffset that removed mention of > UTF-16 and phrased things in terms of String.Encoding and > code-units. For

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

on Thu Jun 22 2017, Kevin Ballard wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md > Given the discussion in the original thread about potentially having > Strings backed by something other than utf16 code units, I'm somewhat > concerned abou

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

The compatibility testing revealed no related errors. And the full test suite only shows one that I listed already. Max > On Jun 27, 2017, at 3:28 PM, Xiaodi Wu wrote: > > This solution is nifty indeed, and has the chief advantage of working. > On Tue, Jun 27, 2017 at 16:55 Max Moiseev via sw

[swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

Swift Evolution, I want to thank the community for the previous feedback for SE-0177 and also address the issue of the proposal being sent back for revisions. The current status being "Returned for revisions" reflects the detailed design section being incomplete and not working against the latest

Re: [swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

RangeExpression is a protocol for all ranges, including partial and unbounded ranges. It would not make sense for such a protocol to have an upper bound or a lower bound. The way in which your proposal could dovetail with RangeExpression is for it to add a requirement to that protocol named `clamp

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

I like it, but I think the implementation can be improved like below. public static func !!(optional: Optional, errorMessage: @autoclosure () -> String) -> Wrapped { precondition(optional != nil, errorMessage()) return optional! } Failures of forced unwrapping are "logic f