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

> > • What is your evaluation of the proposal? > +1, very happy to see this coming together! I've been interested in this feature since the early days of Swift. My only reservation is that I would have expected to be able to access the list of values without any extra annotations. Is there a

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

I don't think anybody wants a big discussion out of this, but if there's a chance that the name will be further revised, then I agree with Nevin, the solo "compacted" is a more appropriate term than "compacting" here. Compacting needs an grammatical object to apply to, so if we wanted to use

Re: [swift-evolution] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

Happy to hear that we went in this direction! Looking forward to the compact method as well. Jarod On Dec 19, 2017, 08:56 -0800, John McCall via swift-evolution , wrote: > Hi, Swift community!  I apologize for the delay in reporting our decision > here; between one

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

The name that feels natural to me would be `sequentiallyEquals`. I don't dispute that the term "lexicographical" is used correctly here, although at least for me personally, it's not a word that I encounter frequently enough to understand what this method would do without reading the

Re: [swift-evolution] commas optional

Ahh, yeah, that does seem like a much trickier case to avoid breaking. My instinct says it's still possible to avoid, but maybe not without lots of complexity. Jarod On Oct 12, 2017, 16:21 -0700, Xiaodi Wu <xiaodi...@gmail.com>, wrote: > On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long

Re: [swift-evolution] commas optional

I don't really expect this sort of syntactic sugar to be popular enough to make it through swift-evolution, and I don't think it's worth the distraction from more important priorities at this time, but for what it's worth, I've enjoyed this feature in other languages that support it. It plays a

Re: [swift-evolution] Enums and Source Compatibility

>From the perspective of primarily an app developer rather than library author, >I'm not a big fan of this change. I find myself in the "unhappy with the loss >of compiler warnings" camp -- if I'm switching over every case of an enum, >then I almost certainly want to be notified that a new case

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

It's hard to say at this point since Jai is in an early state and isn't publicly available yet, but it seems to be working well on a small scale at least from the demos that have been shown. If anyone's curious, this is the video where the feature was originally demoed. It's from the very

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

While we're considering compile-time execution, we should take a look at the `#run` directive in Jon Blow's Jai programming language. It allows you to run arbitrary code in your program at compile time and then utilize the output in your program. This page has a good summary and an example of

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 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] [Review] SE-0168: Multi-Line String Literals

seem likely to gain traction though, so I won't spend more time on it. Thanks again! Jarod On Apr 12, 2017, 16:35 -0700, Brent Royal-Gordon <br...@architechies.com>, wrote: > > On Apr 12, 2017, at 11:58 AM, Jarod Long via swift-evolution > > <swift-evolu

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

This is the most logical newline stripping behavior in my opinion. It's very easy to think about -- all the lines in-between the triple quotes are the contents of the string. Leading and trailing newlines are easily added if desired by adding extra lines. To support that model, I also agree

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> • What is your evaluation of the proposal? I like the feature a lot, but I'm not so sure about the described indentation-stripping behavior. I don't think that putting the closing """ at the same indentation level as the string's contents is very intuitive. It feels a bit like writing this:

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

> • What is your evaluation of the proposal? I think it's great! Enthusiastic +1 from me. Just an idea -- in addition to `mapValues`, it seems like it would be useful to have both a `mapKeys` and plain `map` for key-value pairs. The proposal mentions that `map` was omitted because unique keys

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I don't think an argument label is sufficient to satisfy the first fundamental API design guideline: "Clarity at the point of use is your most important goal." The argument label is not visible at the point of use when using trailing closure syntax, so it provides no additional clarity there.

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On Apr 5, 2017, 13:21 -0700, Xiaodi Wu <xiaodi...@gmail.com>, wrote: > On Wed, Apr 5, 2017 at 2:22 PM, Jarod Long via swift-evolution > <swift-evolution@swift.org> wrote: > > > `integers.all { $0.isEven }` reads like an alias of `filter` to me. The > > > mean

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

`integers.all { $0.isEven }` reads like an alias of `filter` to me. The meaning is ambiguous because the missing argument label can be filled in in different ways -- some will read this as "all are even", and others will read it as "all that are even". I think that ambiguity should be avoided.

Re: [swift-evolution] Type-based ‘private’ access within a file

Pretty bummed out about the rejection. I know it's a petty aesthetic issue, but thinking about having to write "fileprivate" 5 or 10 years from now kills more of my enthusiasm about using the language than I'd like to admit. I think it's going to always be viewed by most as a major wart on an

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Given that this is such a divisive issue, I'd like to see a revised version of this proposal that renames fileprivate back to private but maintains scoped access control under a different name like "scoped", as has been suggested. That seems like the best compromise -- those that want scoped

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> > • What is your evaluation of the proposal? > I think it could stand to make a bit of a stronger case, but I am strongly in favor of the outcome. The introduction of fileprivate was disappointing to me when it happened, and I've yet to encounter a situation where it has been beneficial, but

Re: [swift-evolution] [Discussion] mailing list alternative

Another +1 for Discourse. I'd like to participate more, but the mailing list format is difficult for me to use. I've gone through three email clients since swift-evolution started (Apple Mail, then Airmail, and now Spark), and they work well enough for general, simple email usage, but the