Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jun 30, 2017, at 9:26 PM, Robert Bennett wrote: > > I’m not at a computer to test this, but would this work: > > typealias T = P1 & P2 > extension C: T {} > > Now T is C.Protocol Is C supposed to be a type or a protocol? I’m guessing a protocol since I don’t

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

I’m not at a computer to test this, but would this work: typealias T = P1 & P2 extension C: T {} Now T is C.Protocol > On Jun 30, 2017, at 9:17 PM, Daryle Walker via swift-evolution > wrote: > > >> On Jun 30, 2017, at 8:49 PM, Adrian Zubarev >>

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jun 30, 2017, at 8:49 PM, Adrian Zubarev > wrote: > > What are you proposing here, I don’t get it?! What role should .Protocol > play? .Protocol is an ugly hack in Swift which should be removed anyway. It > does more harm than good. > I’m not proposing

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

What are you proposing here, I don’t get it?! What role should .Protocol play? .Protocol is an ugly hack in Swift which should be removed anyway. It does more harm than good. Our revised proposal was deferred from Swift 4:

[swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

We have MyType.Type to indicate the meta-type of a type. And MyProtocol.Protocol to indicate the meta-type of a protocol. Would it be OK to add MyType.Protocol to identify all the protocols MyType follows? The result would be like if each protocol was connected by

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

Just wanted to throw in my preference for supporting both options. I'd also like to emphasize that !! isn't appealing just for the sake of terseness, but also because it completes the ?, ??, !, !! "family" of unwrapping operators in a way that reinforces their underlying concepts. In that

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

If/when Never is made a bottom time, I suppose this discussion will be moot because it will automatically work with ?? and the compiler would have to go out of its way to prevent that. But until then, I much prefer guard-let-else to the proposed addition to ??. With a guard-let-else, the first

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

> On Jun 30, 2017, at 5:38 AM, Matthew Johnson wrote: > >> 3. If we later change `throw` from being a statement to being a >> `Never`-returning expression, you could use `throw` on the right-hand side >> of `??`. > > What do you have in mind here? I don't recall any

Re: [swift-evolution] Pitch: Documentation access from the Swift REPL

Because this is a REPL change not a language change I recommend you report this as an enhancement request in a radar. ~Robert Widmann > On Jun 8, 2017, at 10:40 PM, Roope Kangas via swift-evolution > wrote: > > > I am new to Swift and just started learning but...

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

These are good points, Brent. > On Jun 29, 2017, at 11:24 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution >> > wrote: >> >> Using an

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

Even if ?? is generally assumed as safe, fatalError would be there to clearly assert what's going on. This is true in general for fatalError, which presence in some code simply means that something could go wrong there, so the regular compilation-level safety cannot be a given. And as forced

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

I have been persuaded that extending the capabilities of the current ?? operator has far more advantages than adding a new limited !! operator. While I initially did not like the usage of the generally-assumed-safe ? for throwing operations, the clarity provided by having to explicitly state

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

These are all excellent points. I also feel they sidestep the motivation of the proposal. Even if there were a bottom `Never` and you could use `?? fatalError()`, I still think the language would benefit from `!!`. As the language is right now, you can write your own "or die" function using a

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

100% agree with everything. A custom operator is a good idea for operations that are actually frequent: once you learn what it means, it really helps reduce noise in code and improve readability. But forced unwrapping is something that's intended to be used sparsely. Elviro > Il giorno 30

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

Sent from my iPad > On Jun 30, 2017, at 12:24 AM, 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

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

+1 Well summarized. The !! operator feels more like: func !! (optional: T?, errorMessage: String) -> T { return optional ?? fatalError(errorMessage) } Which is totally unnecessary. --  Adrian Zubarev Sent with Airmail Am 30. Juni 2017 um 07:24:04, Brent Royal-Gordon via swift-evolution

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

> On Jun 30, 2017, at 1:11 AM, John McCall wrote: > >> >> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution >> > wrote: >> >> Swift is currently an alias-adverse language. The model for the

Re: [swift-evolution] [Pitch] Extending [at]autoclosure

Well as Jordan Rose said on the linked SR, option (1) will probably never happen. Option (3) only makes sense if all of the options are supported (in that case there wouldn’t be any need for explicit @autoclosure, which could simply be merged into the closure type), or (2) is NOT supported so

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

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

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

> On Jun 29, 2017, at 6:45 PM, Beta wrote: > > 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. You’re talking about Apple’s Cocoa’s KVC/KVO, right? The