Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

On Jan 12, 2018, at 4:43 PM, Ted Kremenek wrote: > Hi Chris, > > Instead of responding to each of your point bit-by-bit, I’ll try a different > tactic to explain my reasoning — which may be wrong — by explaining how I see > things top down with the tradeoffs they incur. I’m going to say a bunc

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 12, 2018, at 6:22 PM, Connor Wakamo wrote: > >>> The second case, and the one I’m more worried about, is subclassing. If, >>> for instance, you have the following: >>> >>> class FooView: UIView, CustomPlaygroundRepresentable { >>> var playgroundRepresentation: Any { >>>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 3:08 PM, Jordan Rose wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's > point very specifically: if the compiler emits an error, we should go with > `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) Thanks!

Re: [swift-evolution] [Proposal] Random Unification

> On 13. Jan 2018, at 05:23, Nate Cook via swift-evolution > wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I think we have different definitions of consistency. I am fine with the >> ergonomics of (0…100).random()

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (0…100).random() as a convenience, but it really worries me > here that everything is special cased. Special cased things are

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 6:47 PM, Dave DeLong via swift-evolution > wrote: > > I feel like we’re talking past each other right now, so I’ll give a concrete > example: > > Let’s say MyAwesomeFramework.framework defines this enum: > > enum Access { > case none > case readOnly > c

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Hi Xiaodi, It’s an interesting suggestion. My inclination is that seeding prototype APIs would be better done via source package managers, and not as binary frameworks. But they are two different approaches to the same problem and it is an interesting idea. I’d like to first focus, however,

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 11, 2018, at 11:51 PM, Chris Lattner wrote: > > On Jan 11, 2018, at 11:22 AM, Connor Wakamo > wrote: I don’t think we can change this to return `Any` instead of `Any?`. I think there are potentially cases where a developer might want to selec

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

One point to bring up is that what you call libswiftCoreDeprecated.dylib can be the place that future APIs live until they’re sufficiently mature. I highly doubt that additions to the Swift standard library past 5.0 will all be fully baked on arrival, and having everything carved into stone the mo

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution > wrote: > > I’m definitely in the error camp, but I will go along with a warning if > everyone feels that is better. I see advantages both ways. The fact that the error approach generalizes much cleaner is definitely a plus.

[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Hey Jordan, coming into this a bit late, but it seems like `case #unknown` is the more flexible syntax regardless of warning or error. If typed errors are added then it would fall cleanly into catch pattern matching as well it sounds like. Any thoughts there? And for the record I'm slightly in fav

[swift-evolution] [Review][returned for revision] SE 0192 - Non-Exhaustive Enums

The review of "SE 0192 - Non-Exhaustive Enums” had extensive discussion and has been returned for revision. The proposal author, Jordan Rose, is working on a revised proposal that includes: - Alterations to the naming of the attributes. - New affordances for how switch statements work with non-

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Hi Chris, Instead of responding to each of your point bit-by-bit, I’ll try a different tactic to explain my reasoning — which may be wrong — by explaining how I see things top down with the tradeoffs they incur. I’m going to say a bunch of things I know *you* know, but others are on this threa

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I’m definitely in the error camp, but I will go along with a warning if everyone feels that is better. Thanks, Jon > On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution > wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's > point very specifically:

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 4:24 PM, Jonathan Hull wrote: > > Or what if I want an effect where it randomly fades in letters from a String. Just to explain this example further. I ran into this issue when trying to use arc4random to do this. The eye is really sensitive to patterns in cases like t

Re: [swift-evolution] [Proposal] Random Unification

I think we have different definitions of consistency. I am fine with the ergonomics of (0…100).random() as a convenience, but it really worries me here that everything is special cased. Special cased things are fine for individual projects, but not the standard library. We should make sure th

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I feel like we’re talking past each other right now, so I’ll give a concrete example: Let’s say MyAwesomeFramework.framework defines this enum: enum Access { case none case readOnly case readWrite } This framework is compiled, built, and embedded in to MyAwesomeApp.app/

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 4:22 PM, Jordan Rose wrote: > > No, it's "Revision-locked imports”. Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied in this library”. > A source-breaking change is one in which updating the library at compile time > will break clients at comp

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

No, it's "Revision-locked imports". A source-breaking change is one in which updating the library at compile time will break clients at compile time. That's relevant for libraries distributed with an app as well as for libraries that are part of the OS. You may not care, but I do, and I think o

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I assume you’re referring to this? Implicitly treat enums without binary compatibility concerns as @frozen Several people questioned whether it was necessary to make this distinction for libraries without binary compatibility concerns, i.e. those that are shipped with their client apps. While th

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I included that, but also I again don't think that's the correct design. There's a case where that's useful, but that shouldn't be the default, and I don't think it's important enough to do in Swift 5. Jordan > On Jan 12, 2018, at 15:15, Dave DeLong wrote: > > Unless I’m missing something, t

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Unless I’m missing something, this is still missing the discussion on being able to treat all enums of internally-packaged libraries as frozen. IE, that frozen vs unfrozen is only an issue for enums that come from modules that are not packaged with your app. Dave > On Jan 12, 2018, at 4:08 PM,

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Okay, I went back to `unknown case` in the proposal, but mentioned Chris's point very specifically: if the compiler emits an error, we should go with `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) I think the revised proposal is in good shape! (https://github.com/ap

Re: [swift-evolution] [Proposal] Random Unification

We are doing crazy contortions to avoid the 'random % 100’ issue. Why not just check for that pattern and issue a warning with a fixit to do it better? I don’t think it is worth handicapping everything just to avoid this. Thanks, Jon > On Jan 11, 2018, at 11:22 PM, Nate Cook via swift-evoluti

Re: [swift-evolution] [pitch] adding toggle to Bool

I also avoid using ! for negation when possible, and `toggle` or `invert` will be helpful, but in many cases I think the negative case is better expressed directly. For example, I find that using `nonEmpty` instead of !isEmpty makes the code easier to read: extension String { var nonEm

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

> On Jan 12, 2018, at 2:00 PM, John McCall via swift-evolution > wrote: > > >> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree that this behavior is annoying. However, wouldn’t it be >> source-breaking to change this now?

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution > wrote: > > I agree that this behavior is annoying. However, wouldn’t it be > source-breaking to change this now? Source compatibility means that we can't change the behavior of Swift 3 / Swift 4 source. This would be a semantic

Re: [swift-evolution] [pitch] adding toggle to Bool

All I meant is that it’s usage should fade, which is my personal opinion. That said, I didn’t meant to say it should be removed or something. ;) Am 12. Januar 2018 um 20:54:16, Alejandro Martinez (alexi...@gmail.com) schrieb: I wouldn't go as far as to ask to fade out ! but in all my code I end

Re: [swift-evolution] [pitch] adding toggle to Bool

I wouldn't go as far as to ask to fade out ! but in all my code I end up doing == false just for readability. That ! knows who to hide himself too well :P On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution wrote: > I’m not sure if this would be considered or not, but I would lik

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Sent from my iPhone > On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about the new #unknown behavior. Is it

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > wrote: > >> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: On Jan 11, 2018, at 11:15 PM, Jean-Dan

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Sent from my iPad > On Jan 12, 2018, at 12:25 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about the new #unknown behavior. Is

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 23:30, Chris Lattner wrote: > > >> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >> wrote: >> >> A question about the new #unknown behavior. Is it intended to be used for >> error handling too ? >> Will it be possible to use in catch clause ? > > If w

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

This is not an optional-chaining issue *per se*. If you simply write, let a = try? SomeType().doThrow() // a has type SomeType?? you get a double-optional as well. Are you proposing to change that? Nevin On Fri, Jan 12, 2018 at 12:25 PM, Russ Bishop via swift-evolution < swift-evolution@swift

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

I agree that this behavior is annoying. However, wouldn’t it be source-breaking to change this now? -BJ > On Jan 12, 2018, at 10:25 AM, Russ Bishop via swift-evolution > wrote: > > Greetings swift-evolution! > > There is currently a disconnect between optional chaining and try? when it > co

[swift-evolution] [Pitch] Make try? + optional chain flattening work together

Greetings swift-evolution! There is currently a disconnect between optional chaining and try? when it comes to optional flattening: struct SomeType { func nonThrow() -> SomeType? { return self } func doThrow() throws -> SomeType? { return self } func nonOptional() throws -> SomeType

Re: [swift-evolution] [pitch] adding toggle to Bool

+1 for toggle, seems the clear winner for me. > On Jan 12, 2018, at 8:29 AM, Cheyo Jimenez via swift-evolution > wrote: > > It’s a slippery slope because it makes me want to have something like `not()` > added to the library. I don’t think it’s worth it. > I would love to have not(), but fo

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 12, 2018, at 12:14 AM, Nate Cook via swift-evolution > wrote: > > >> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution >> wrote: >> >> Hey SE! >> >> When we have a bunch of nested structs: >> >> struct Sample { >> var bar: Bar >> } >> >> str

Re: [swift-evolution] [Proposal] Random Unification

Done and done! Sent from my iPhone On Jan 12, 2018, at 01:22, Nate Cook mailto:natec...@apple.com>> wrote: On Jan 11, 2018, at 9:17 PM, Alejandro Alonso mailto:aalonso...@outlook.com>> wrote: Sorry it takes me forever to respond! I finally got around to writing this! School really takes all

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 11, 2018, at 11:42 PM, Brent Royal-Gordon > wrote: > >> On Jan 11, 2018, at 4:21 PM, Paul Cantrell > > wrote: >> >> This raises a question related to Chris’s: what is the utility of having >> Limb conform to a protocol instead of just providing allValues a

Re: [swift-evolution] [pitch] adding toggle to Bool

Agree: toggle makes the most sense to me as well. On Fri, Jan 12, 2018 at 06:14 David Hart via swift-evolution < swift-evolution@swift.org> wrote: > > > On 12 Jan 2018, at 07:15, Chris Eidhof via swift-evolution < > swift-evolution@swift.org> wrote: > > Hey SE! > > When we have a bunch of nested s

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution > a écrit : > > On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about the new #unknown behavior. Is it intended to be used fo

Re: [swift-evolution] [Proposal] Random Unification

Give up* Sent from my iPhone On Jan 12, 2018, at 08:10, Alejandro Alonso via swift-evolution mailto:swift-evolution@swift.org>> wrote: I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent from my iPhone On Jan 11, 2018, at 21:28, Xia

Re: [swift-evolution] [Proposal] Random Unification

(0 ..< 10).random() would return an optional Int.random(in: 0 ..< 10) would return a non optional (this is the one that crashes on bad range) Sent from my iPhone On Jan 12, 2018, at 07:11, Letanyan Arumugam mailto:letanya...@gmail.com>> wrote: Nate’s design follows a consistent idea of getting

Re: [swift-evolution] [Proposal] Random Unification

I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent from my iPhone On Jan 11, 2018, at 21:28, Xiaodi Wu mailto:xiaodi...@gmail.com>> wrote: On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via swift-evolution mailto:swift-evolution@

Re: [swift-evolution] [Proposal] Random Unification

Nate’s design follows a consistent idea of getting a random value from some set of values. Adding the static method random() to a type essentially creates an implicit set which you yourself said leads to inconsistency (Double/Int). Secondly I don’t see why random(in:) should be added when it is

Re: [swift-evolution] [pitch] adding toggle to Bool

> On 12 Jan 2018, at 07:15, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo = Sample(bar: Bar(show: false))

Re: [swift-evolution] [pitch] adding toggle to Bool

I’m not sure if this would be considered or not, but I would like if the negation operator `!` would fade out. If this is ever going to a review then I’d suggest that we add a pair of functions, one mutating and the other non-mutating. extension Bool {   mutating func invert() {     self = !sel

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

On 11.01.2018 1:54, Jordan Rose via swift-evolution wrote: [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md] I think this is generally reasonable, and none of the names offend me enough to weigh in on that discussion. I do think

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution wrote: A question about the new #unknown behavior. Is it intended to be used for error handling too ? Will it be possible to use in catch clause ? If we go with the

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo = Sample(bar: Bar(show: fals