> • 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. Redu
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
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/
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
“eleme
> 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
> S
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
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 al
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 listin
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
> 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 be safer if it was an error.
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 annota
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 th
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 make
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 (comparin
> 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, but sometimes you ended up
>
>> “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
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 someCriteria
>* 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 is
+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 Swift community,
>
> The r
> * 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 do
One comment Inline
> On 20 Jul 2016, at 07:58, Charlie Monroe via swift-evolution
> wrote:
>
> I'd personally leave it as is, but am kind of indifferent on the matter.
>
> The subscript is a hybrid between var and func and with the arguments, it
> always felt more of a function to me, without
+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 significant enough to warrant
>* 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 (l
>* 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 b
like the above, I’m fine with changing the way it’s
defined / works internally.
- David
> On 07 Jul 2016, at 10:07, Haravikk wrote:
>
>
>> On 6 Jul 2016, at 21:13, David Rönnqvist via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>&
> * 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
>* 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 signi
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, T
>* 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 s.withUTF8Buffer(proc
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:
>
>
> https://github.co
> 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 some questions you might wan
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 th
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 block/lam
+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 sam
> 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 mean *sorted*(by:) ? Or I'm missing something in naming rules?
>>
>> IIRC, so
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 s
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
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 appreciate the work that we
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 Objective-
>* 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 b
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 from my iPhone
>
>> On Jun 20
> 31 maj 2016 kl. 21:37 skrev Chris Lattner :
>
>> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution
>> wrote:
>> Lazy evaluation when assigning static variables
>> Introduction
>> Both stored type properties (static) and lazy stored
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 t
>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 static property i
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 lazy variables evaluated (or -
> • 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
* 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
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, Kryst
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 `average
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
> * 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 I’v
> 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:
>
>
> https://github.com/apple/swift-evolution/blob
> 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:
>
>
> https://github.com/apple/swift-evolution/blo
Would this also affect the syntax for naming closure arguments? For example,
would this (taken from "The Swift Programming Language (Swift 2.2)”):
reversed = names.sort( { s1, s2 in return s1 > s2 } )
have to be written like this:
reversed = names.sort( { (s1, s2) in return s1 > s2 } )
or is t
By “the big three”, are you referring to only the naming of map, filter, and
reduce?
I would also like to see a formal proposal along these lines, and possibly
more.
I also feel that the `inPlace` suffix was very clear (most important) and very
much liked that it made the immutable version t
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 is
I noticed a difference between how static and lazy variables evaluate closures
and thought that it was a bug:
https://bugs.swift.org/browse/SR-1178
but apparently it’s not.
The difference can be illustrated in a small example. The following code will
evaluate the closure for the static variable,
> > 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 mu
57 matches
Mail list logo
