Re: [swift-evolution] SE-0171: Reduce with inout

> • What is your evaluation of the proposal? +1 This is a small, but very useful addition. I like the argument label `into`, and using it to distinguish between the two implementations. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes.

Re: [swift-evolution] 'Random' Improvements

I’m just going to mention that there was a tiny discussion about Random in early March (only five messages, all linked to below). That thread discussed the different expectations/understandings of “random”. Regards, David

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

I agree that `all(equal:)` and `all(match:)` are really good names for these methods (I could also consider `every`). In my understanding of the Swift API Design Guidelines, it’s good for a number of reasons: It omits needless words. It’s a sequence of Element, so explicitly mentioning

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

> What is your evaluation of the proposal? I’m positive towards this proposal in isolation. It’s a step in the right direction. But I also feel that it doesn’t fully address the larger issue around access control. > Is the problem being addressed significant enough to warrant a change to >

Re: [swift-evolution] [Proposal] Factory Initializers

Forgive me if that has already been discussed in the email threads prior to the proposal, but what I’m missing from this proposal is a discussion of the problems factory initializers solve (other than the examples at the end) and an explanation of why factory initializers are the right solution

Re: [swift-evolution] Code blocks and trailing closures

Xcode can already draw boxes for nesting scopes, but it’s disabled by default. You’ll find it under: Editor > Code Folding > Focus Follows Selection. That said, IIRC it’s been mentioned on this list that (I’m paraphrasing) we should try and avoid designs that rely on editor functionality, and

Re: [swift-evolution] [draft] Add `clamped(to:)` to the stdlib

It might be worth mentioning (for background) that the various Range types already have a `clamped(to:)`. The proposed solution is consistent with that (as opposed to for example a free function). I’m not sure if a free function should be considered an alternative. It’s probably fine not

Re: [swift-evolution] final + lazy + fileprivate modifiers

I searched thought my code and most uses of fileprivate were for same-file extensions which would be solved by #2 as well. The other usages are mostly "related" types, which could possibly work with #2 if these were made inner types instead. Two examples: A "Slots" struct with a collection of

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution > wrote: > > +1, two small questions: > > - If two cases have the same base name but different full names, will > matching on the base name match both cases, or will it be an error? I feel that it would

Re: [swift-evolution] [Idea] Add @pure annotation or keyword to force pure functions

It could be nice to have something similar to the @effects attribute, _but_ where the compiler could tell if the annotation was valid or not. Meaning that if I believe a function to be pure, I could annotate it as such. If the compiler notices that I'm reading from some global state, that

Re: [swift-evolution] [Proposal draft] Add `Clamp` function to standard library

There is already a `clamped` function for clamping one range to another and I feel that this function should be consistent with that one. As I see it, it can either be consistent in that it takes a Range as its argument, or in being an extension to Range. Probably something like either one of

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

I have some problems understanding the scope of this proposal. More specifically if it’s limited to arrays and dictionaries or if it’s broader than that, and if it’s limited to objects that originate in Swift or if the same applies for objects that originate in Objective-C code. For me, it

Re: [swift-evolution] [Discussion] Sortable Attribute

Haskell also has a `comparing` function comparing :: (Ord a) => (b -> a) -> b -> b -> Ordering which applies a function on both the left hand side and the right hand side to get two values that can be compared/ordered. This makes the call site look something like this: sortBy

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On 15 Aug 2016, at 15:29, Justin Jia via swift-evolution > wrote: > > IMO `if x? { }` is not a lot shorter than `if let x = x`. > > The problem with `if let` is, you need to explicit specify { } and call the > function inside it. It is good for being explicit,

Re: [swift-evolution] ABI of throwing

>> “Zero cost” EH is also *extremely* expensive in the case where an error is >> actually throw in normal use cases. This makes it completely inappropriate >> for use in APIs where errors are expected in edge cases (e.g. file not found >> errors). > > Anecdote: I work with a web service that

Re: [swift-evolution] [Idea] return if / return unless

One complication with allowing postfix conditionals for all statements is that it often needs to have an else clause as well (like the ternary operator “?:"). For example, what’s the type of “x” below? let x = 5 if someCriteria() And is “y” initialized or not? let y: Int y = 42 if

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

>* What is your evaluation of the proposal? -1. I think that there might be something to this idea, but am against the proposal in its current form for the same reasons that have already been stated: flatten has a broader use than just joining sequences/collections, and flatten as a name

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

+1. A small but good improvement. It makes even more sense since the documentation for these calls it “null-terminated” (was called “nul-terminated” in the 2.2 documentation). - David > On 25 Jul 2016, at 08:18, Chris Lattner via swift-evolution > wrote: > > Hello

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> * What is your evaluation of the proposal? +1 In its third revision I like this proposal more. I think “open” is a good keyword for both members and classes. I’m in favor of the first design for open classes. That said, I also acknowledge that subclassing without overriding anything

Re: [swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1. Agreed. A minor but a clear improvement for clarity and consistency. - David On 16 Jul 2016, at 07:54, Jacob Bandes-Storch via swift-evolution wrote: >> * What is your evaluation of the proposal? > > +1 > >> * Is the problem being addressed

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

>* What is your evaluation of the proposal? -1. I agree that there is a problem with optional coercion for the ?? operator (and have on occasion encountered the type of bugs/mistakes that the proposal mentions). However, I'm against the proposed solution to that a problem. Some operators

Re: [swift-evolution] [Review] SE-0120: Revise 'partition' Method Signature

>* What is your evaluation of the proposal? +1. After seeing an example of the current partition method (which I hadn't heard of before that) on the mailing list I tried to use it in our code, but it was too specialized for it to be a good fit. The new proposed method is more flexible and

Re: [swift-evolution] Removing Variadic Parameters.

like the above, I’m fine with changing the way it’s defined / works internally. - David > On 07 Jul 2016, at 10:07, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 6 Jul 2016, at 21:13, David Rönnqvist via swift-evolution >> <swift-evolution@swi

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? +1 (almost exclusively) Writing good library code is hard and a lot of code isn't actually written to be externally subclasses (and trying to plan for subclassing can be difficult). Our team also writes "final class" in a lot of places and I don't

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

>* What is your evaluation of the proposal? +1. I find this to be a solid, well reasoned proposal. I enjoyed seeing such a detailed Motivation and am looking forward to discussing the Related Proposals and Future Directions mentioned in this one. >* Is the problem being addressed

Re: [swift-evolution] Removing Variadic Parameters.

I'd be reluctant to remove variadic parameters. We've found on our team that variadic arguments are easier to read on the call site compared to array arguments, especially when it's common to pass a single value (but still possible to pass multiple values). - David > On 6 Jul 2016, at 20:38,

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

>* What is your evaluation of the proposal? +1. These look like good improvements to me. (I'm also happy that the map/filter/reduce naming was left out of this proposal) One thing I was wonder about was the capitalization of UTF8 in the first example. Shouldn't that be

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Sent from my iPad > On 1 Jul 2016, at 08:02, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0113: Add integral rounding functions to FloatingPoint" > begins now and runs through July 5. The proposal is available here:

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On 1 Jul 2016, at 14:13, Taras Zakharko via swift-evolution > wrote: > >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and contribute to the direction of Swift. >> When writing your review, here are

Re: [swift-evolution] [Proposal] Sealed classes by default

All bike-shedding aside, I see two parts of this proposal and I come down on different sides for the two. 1. Introducing a new class modifier that acts as final outside the defining module 2. Changing the default to this new modifier (and thus also introducing a third explicit class modifier

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

Is this (below) the list you were referring to? (copied from: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/021301.html ) - David —— `map`, `filter`, and `reduce` are *the* higher-order functions. Almost anything with any kind of

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

+1. This makes sense to me. Since the API Guidelines say: “Prefer methods and properties to free functions”, it would make sense to add sugar like this to make methods just as convenient and clear to pass to higher order functions as free functions currently are. I’m also wondering if the

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On 24 Jun 2016, at 16:26, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 24, 2016, at 4:11 PM, Anton Zhilin via swift-evolution >> wrote: >> >> Vladimir.S via swift-evolution writes: >> >>> Do you

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

We’ve also got two occurrences in our closed source, production code: for (predicate, callback) in predicatesAndCallbacks where predicate(typedEvent) { callback(typedEvent) } and: for conversation in conversations where conversation.state == .Established { } They’re both quite simple and

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

I don’t know about the chances of getting approved, but I think this is something worth discussing. It might just be my ignorance, but I can’t think of a good reason why a function argument would be force unwrapped. Either it’s non-null and the caller is expected to unwrap it or it’s nullable

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

I prefer "\" as the consistent escape character in Swift. It's used in many programming languages and (I find it) easy to skim over. - David > On 23 Jun 2016, at 22:21, James Hillhouse via swift-evolution > wrote: > > I’m going to register a -1 on this proposal. I

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

I'm not convinced that Swift needs more than on way of representing the lack of a value. As far as I've understood (and remember), NSNull main reason to exist is that it's an actual object and won't for example terminate array literals. From what I've observed of people who are new to

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

>* What is your evaluation of the proposal? +1. It's a positive change. It makes un-annotated code safer, and it moves the annotation to the case where one needs to think about captures as opposed to annotating the case where one doesn't have to think about captures. >* Is the problem

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

Would this proposal in any way be related to `throw`ing properties (more specifically throwing setters)? Or would that be a completely different discussion/proposal? - David > On 20 Jun 2016, at 21:27, Matthew Johnson via swift-evolution > wrote: > > > > Sent

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> 31 maj 2016 kl. 21:37 skrev Chris Lattner <clatt...@apple.com>: > >> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution >> <swift-evolution@swift.org> wrote: >> Lazy evaluation when assigning static variables >> Introduction >&g

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Under "Proposed solution" you say (emphasis mine): "Make return optional and infer return type for single-expressions everywhere in the language:" However the return type isn't inferred for computed properties or functions, and I don't see type inference being discussed in the proposal (other

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

;print(Foo.test) >print("2") >Foo.bar = "Set" >print("3") >let foo = Foo() >foo.baz = "Set" >print("4") > > we have : > 1 > test > 2 > static > 3 > 4 > > I strongly believe as

[swift-evolution] [Draft] Lazy evaluation when assigning static variables

It appears that this email never showed up on the list. I'm sending it again, with the risk of it appearing twice later. > 30 maj 2016 kl. 22:56 skrev Gmail : > > Several weeks ago I posted that I was confused by the differences between how > static variables and

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> • What is your evaluation of the proposal? Mixed. But I think it leans towards the negative. At first I thought it was a big improvement, but after looking at how our team currently writes guard statements, the where clause is almost always using the unwrapped value (as opposed to an

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

* What is your evaluation of the proposal? +1. These are useful additions to the standard library. Naming the first argument `initial` (in the `T->T?` variant) is consistent with `reduce` and makes it clear (to me) that the initial value is part of the result. * Is the problem

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Forget me if I'm wrong, but wouldn't localization requirements make string interpolation unsuitable for user facing strings anyway? (I remember localization being discussed previously, but don't recall it turning into a proposal) - David Sent from my iPhone > On 19 May 2016, at 19:06,

Re: [swift-evolution] [Pitch] Constrains for numeric types: Int<1...10> Double<0.0...1.0>

It reminds me of "Refinement Types" (see for example [this blog post][1] or [this paper][2]). I generally think it’s a cool idea and that it can be useful in minimizing partial functions by requiring that these cases are explicitly handled. For example, highlighting that the following

Re: [swift-evolution] Disallow arbitrary expressions in selectors

I noticed in our code that we had one occurrence of #selector(SomeClass().someFunction) which to my eyes looked like a bug. Disallowing arbitrary expressions looks very reasonable to me and would help catch small mistakes like this one. > 29 apr. 2016 kl. 16:40 skrev Thorsten Seitz via

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

> * What is your evaluation of the proposal? +1 This is a useful addition. As other have already pointed out, I also feel that `scan` is the least intuitive name among these and that the `reduce`/`reductions` pairing would do a good job at explaining the relation between the two. If

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> On 25 Apr 2016, at 19:27, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0069: Mutability and Foundation Value Types" begins now and > runs through May 4. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

> On 26 Apr 2016, at 06:20, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "Allow (most) keywords in member references" begins now and > runs through April 29th. The proposal is available here: > > >

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I don’t particularly like these name changes. I would even go as far as saying that these recent discussions about renaming flatten, map, filter, reduce has made me question the original Swift 3 API renaming. What I mostly like about the current (2.2) naming is that the non-mutating version

[swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

> > On Jan 10, 2016, at 10:20 PM, Kevin Ballard via > > swift-evolutionwrote: > > > > When the proposal is "we have a bunch of functions that match functions > > used in other languages, lets add a few more from the same category of > > functions that we missed", does there really need to be