Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I’ve never seen anyone use the empty init for it before, and if I ever will, I’ll probably discourage it. What is it for, anyways? Isn’t `Int.allZeros` enough? > On 26 Dec 2016, at 18:09, David Sweeris <daveswee...@mac.com> wrote: > > >> On Dec 26, 2016, at 09:01, Ti

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Then why is Int() allowed, and why does that return 0? > on Sun Dec 25 2016, Xiaodi Wuwrote: > > > On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek > > wrote: > > > > > There's a book that provides quite a bit of info on this > > > > > >

[swift-evolution] try?, precedence and double optionals

Given the function func mightReturnInt() throws -> Any { return 3 } combining `try?` and `as?` has a somewhat unexpected result: if let int = try? mightReturnInt() as? Int { print(int) // => Optional(3) } You’d need to add parentheses to end up with a non-optional: if let int = (try?

[swift-evolution] [pitch] rename 'guard' to 'ensure'

I don’t really mind the “guard” keyword after having used it hundreds of times, but it didn’t really make a lot of sense to me to start with (I’m not a native speaker). “ensure” definitely conveys the meaning better, in my opinion. I’d be in favor of this change. I bet most people won’t think

[swift-evolution] Using `map` and `flatMap` with implicit optionals

This could cause problems when the underlying type also has a `map` or `flatMap` function: let array: [Int]! = nil array.map { $0 } // crash Should this use Optional.map or Array.map? As a workaround, you can simply do let array: [Int]! = nil (array as Optional).map { $0 } // nil > Since

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

n you assign a new value. > c) when get and set aren't implemented with a matching hidden var (i.e. using > a bit in an int var or storing in a dictionary). > > > On Tue, 11 Oct 2016 at 11:26 Tim Vermeulen via swift-evolution > <swift-evolution@swift.org <mailto:swift

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

in a dictionary). I’m not sure what you mean by this. The getter and setter are implemented, but the mutator isn’t? Could you clarify? > > > On Tue, 11 Oct 2016 at 11:26 Tim Vermeulen via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

, or what it does could be seemingly unrelated to the `get` clause, so it’s not a trivial task to optimise this. > On 11 Oct 2016, at 06:35, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution >> <swift-evo

[swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

There have been many instances where unexpected bad performance was caused by the interplay between getters, setters, mutations and the copy-on-write mechanism. For example: struct Foo { private var _array: [Int] = [1, 2, 3, 4, 5] var array: [Int] { get { return _array }

[swift-evolution] [Proposal] Enums with stored properties

This is precisely what a struct is for, why would you want to be able to do this with enums instead? > Hi all, > I would like to know you opinion on one feature I feel would be a real 'nice > to have' extension to currently available enumeration type. Which is an > enumeration type with stored

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

st `switch?`: it undermines the exhaustiveness > guarantee of the switch statement and is wholly inconsistent with Swift usage > of `?`, which indicates the possibility of an Optional. We simply don't need > a new spelling for `default: break`. > On Tue, Oct 4, 2016 at 3:35 AM Tim

[swift-evolution] [Pitch] Can we make `default` on switches optional?

I agree about exhaustiveness checks being very useful. There was a suggestion for `switch?` implicitly adding `default: break`, `switch!` implicitly adding `default: fatalError()`, and `switch` remaining as it is now. I think that’s a great compromise, would you be in favor of that? > -1. The

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

>>> >>>>>>> The whole point is to be used in a for loop. If it was a collection >>>>>>> then you'd need to have an index for that collection, so now you have >>>>>>> an index that lets you get the index for another

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

cause you could just be using that underlying index to begin >>>>> with. >>>> >>>> Rather than introducing a new index for this, we can simply use the index >>>> of the base collection for subscripting. >>> >>> That's actually a

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

f >> the base collection for subscripting. > > That's actually a good idea, and if we do make it a collection this is > probably how we should handle it. But I still argue that the ability to make > something a collection doesn't mean it should be a collection, if there's n

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

that underlying index to begin with. Rather than introducing a new index for this, we can simply use the index of the base collection for subscripting. > > -Kevin > > On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote: >> +1 for `indexed()

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

This wasn’t the default behaviour because `enumerated()` is a method for the `Sequence` protocol, which doesn’t have any indices. Integers are the only thing that make sense there. But I agree that this should have been part of the standard library already. > +1.One of those things where you

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

On Sep 7, 2016, at 12:58 PM, Tim Vermeulen via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> They’re still in Swift 3. Did something go wrong, or will they simply not >> show up in the final Swift 3.0? > > Please elabo

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

The new integer protocols (Arithmetic, FixedWidthInteger, etc) aren’t supposed to be in Swift 3.0, right? They show up in the latest snapshot. > On 9 Sep 2016, at 01:35, Chris Lattner <clatt...@apple.com> wrote: > > On Sep 7, 2016, at 12:58 PM, Tim Vermeulen via swift-evol

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

They’re still in Swift 3. Did something go wrong, or will they simply not show up in the final Swift 3.0? > On 10 Aug 2016, at 22:28, Dave Abrahams wrote: > > > on Wed Aug 10 2016, Tim Vermeulen > wrote: > >> Some protocols of SE-0104 seem

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

quence<(Iterator.Element, Iterator.Element)> { >return AnySequence(zip(self, self.dropFirst())) > } > } > > Does it have the right behavior? > > Max > >> On Aug 29, 2016, at 9:45 AM, Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org> wrote:

[swift-evolution] [Idea] Add `bounds` function to standard library

What would the point of a free function be if you already have a protocol extension? > Georgios, Yes lets go with clamp for a name! > > Pyry, Originally I thought of just adding a global function akin to `min` > and `max` but I am also > in favour of adding the above extension to `Comparable`.

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

process, so > > > > > waiting for another opinion for a day or two won’t change > > > > > anything, really. > > > > > > > > > > Meanwhile, I played a little bit with an idea of making `first.map { > > > > > sequence(fir

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

> > On Aug 20, 2016, at 02:26, Tim > > Vermeulenwrote: > > What you’re saying makes sense, and I might not have brought this up in the > > first place if `first.map { sequence(first: $0, next: next } ?? []` worked. > > The main annoyance is that the

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

e. One > > > downside is that the `ExpressibleByArrayLiteral` protocol allows creating > > > non-empty sequences as well, which does not make sense for the > > > `UnfoldSequence`. > > > > > > > > > Max > > > > > >

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

What do you find so useful about them? And in what context does it make sense to you that `nil < .some(x)` always evaluates to true? When I found that out, I was very surprised by that behaviour (just like many others). Do you have examples of then an optional comparison makes the code clearer?

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

ot make sense for the `UnfoldSequence`. > > > Max > >> On Aug 19, 2016, at 3:48 PM, Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 19 Aug 2016, at 19:48, Ke

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

ange the type of `first` to an Optional, it would make the >>>> termination condition non-trivial. After all, the only thing it would do >>>> is try to unwrap the `first`, before doing what it needs to, but we >>>> already have a `map` for that. One should be

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Map({$0})` (or even `.lazy.flatMap({$0})`) will do the right thing > without making an API more complex. > > I see the point of `sequence(first:next:)` to be precisely the "generate the > non-empty sequence using a seed and a simple producer", for anything more > than that

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

$0?.frobnicate() }) >> >> If first could be of type `T` or `T?`, is bar of type `UnfoldSequence` or >> `UnfoldSequence<T?>`? >> On Mon, Aug 15, 2016 at 17:15 Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.or

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

equence(first: foo, next: { $0?.frobnicate() }) > > If first could be of type `T` or `T?`, is bar of type `UnfoldSequence` or > `UnfoldSequence<T?>`? >> On Mon, Aug 15, 2016 at 17:15 Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org> wrote: >>

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

gt; >>>> You can’t; the `first` parameter has type `T`, not `T?`. >>>> >>>>> On 15 Aug 2016, at 22:10, Maximilian Hünenberger <m.huenenber...@me.com >>>>> <mailto:m.huenenber...@me.com>> wrote: >>>>> >

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

> On 15 Aug 2016, at 22:08, Xiaodi Wu wrote: > > > > On Mon, Aug 15, 2016 at 3:05 PM, Charles Srstka > wrote: >> On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution >>

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

> On 15 Aug 2016, at 21:27, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 1:57 PM, Haravikk via swift-evolution > > wrote: > >> On 15 Aug 2016, at 13:44, Tim Vermeulen >

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

> > On 15 Aug 2016, at 08:02, Justin Jia via > > swift-evolutionwrote: > > Hi! > > > > I don’t know if this has came up before. I tried to search though the > > mailing list but didn’t find any related threads. > > > > This is purely

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

Some protocols of SE-0104 seem to be part of the latest Swift 3 snapshots (Arithmetic, FixedWidthInteger, etc) - was this a mistake then, if they won’t be in Swift 3.0? > on Wed Aug 10 2016, Ben Rimmingtonwrote: > > > > On 10 Aug 2016, at 00:36, Dave Abrahams wrote: > > > > > > > on Tue Aug

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

For what it’s worth: Discourse has a Mailing List mode, which will send you an email every time someone makes a new topic or replies to an existing topic (apart from the topics you muted). You can then reply to that email to post a reply in that topic, just like in a mailing list. > On 8/2/16

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

makes it easier to reference to the patches within ZenHub > than from Discourse or other forums. Swiftly right? > > https://www.zenhub.com > > On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)&g

[swift-evolution] [Swift4] Mailing list vs. Forum

+1. Hirundo makes this format bearable, but it is still far from ideal. I see many advantages for using Discourse: - It has actual syntax highlighting. - It’s easier to moderate. - It supports real-time updates. - It’s easier to follow the flow of a conversation. - It has better search. I don’t

Re: [swift-evolution] Arrays and variadic parameters

I agree mostly with what you’re saying, but variadic parameters don’t actually require at least one element. `max` simply returns a non-optional because its function signature has three non-variadic parameters as well: public func max(_ x: T, _ y: T, _ z: T, _ rest: T...) -> T > This has been

Re: [swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

Great! A +1 from me for that proposal then :) > > On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via > > swift-evolution<swift-evolution@swift.org>wrote: > > > > `firstIndex` is completely unambiguous, whereas with `index` people might > > wonder which in

[swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

`firstIndex` is completely unambiguous, whereas with `index` people might wonder which index is returned. Also, if `lastIndex` methods ever get added to the standard library, they will be a lot more consistent with `firstIndex` than with `index`. On the other hand, `index` is short and simple,

[swift-evolution] [Pitch] Rename flatten() to joined() and give joined() for string sequences the empty string as the default parameter

Currently someSequence.joined(separator: []) someSequence.flatten() (where someSequence is a sequence of sequences) results in two equal sequences (apart from their exact types). I would like to have flatten() renamed to joined(), resulting in joined(_:) seemingly having an empty array as the

Re: [swift-evolution] [Pitch] Giving functions default return values

ot;continue" in here > } > > // ... > } > > >> On Jul 13, 2016, at 4:57 PM, Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> This idea is purely additi

[swift-evolution] [Pitch] Giving functions default return values

This idea is purely additive and isn’t to be considered for Swift 3. Oftentimes a function has a very obvious default argument to fall back on. If the return value is optional, this is generally nil. If the return value is Bool, it’s probably `false`. Often this fallback value is returned at

Re: [swift-evolution] Change subscripts to use colons

I wasn’t suggesting named subscripts :) As you seem to have figured out, that gets confusing pretty quickly. Writing `self.items[0 ... 1]` seems a bit silly because the use of a subscript already implies items of some kind. So, to be clear, I was suggesting computed properties that allow

Re: [swift-evolution] Change subscripts to use colons

bscript image(for: UIControlState): UIImage? { > get { … } > set { … } > } > >> On 12 Jul 2016, at 00:29, Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>

Re: [swift-evolution] Change subscripts to use colons

image(for: .normal) = image over button[imageFor: .normal] = image > On Mon, Jul 11, 2016 at 3:00 PM, Tim Vermeulen via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Slightly related to this, I would really love to have non-subscrip

[swift-evolution] Change subscripts to use colons

Slightly related to this, I would really love to have non-subscript parameterized properties. It would allow us to write button.image(for: .normal) = image instead of button.setImage(image, for: .normal) The same can be achieved through subscripts, but it’s not always as nice. It would bring

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> on Wed Jul 06 2016, Tim Vermeulenwrote: > > > This is a follow up from this swift-users thread: > > https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html > > > > As it stands, RangeReplaceableCollection requires an implementation > > for

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 16:57, Karl <razie...@gmail.com> wrote: > > >> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This is a follow up from this swift-users thread: >> https://lists.s

[swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

This is a follow up from this swift-users thread: https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html As it stands, RangeReplaceableCollection requires an implementation for init(), which is used in the default implementations of (as far as I can tell) init(_:),

Re: [swift-evolution] Shorthand unwrap proposal

wift.org)>wrote: > > > > > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via > > > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote: > > > > > > I would love to be able to do something like > > > > &

Re: [swift-evolution] Shorthand unwrap proposal

gt; > > On Jun 23, 2016, at 8:52 PM, Tim Vermeulen<tvermeu...@me.com>wrote: > > > > Why with the exclamation mark? It suggests you’re force unwrapping > > something. > > > > > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via > > > > swi

Re: [swift-evolution] Shorthand unwrap proposal

Why with the exclamation mark? It suggests you’re force unwrapping something. > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via > > swift-evolution<swift-evolution@swift.org>wrote: > > > > I would love to be able to do something like > > > > doSo

Re: [swift-evolution] [Proposal] Remove eager `map` and `filter`

They can’t have `rethrows` either. > > 1. Make sure that > > > > Array(sequence.lazy.map { ... }) and sequence.map { ... } > > Array(sequence.lazy.filter { ... }) and sequence.filter { ... } > > > > are just as fast (with -O). "Fix lazy filter" proposal should help with > > this. > > > > 2.

Re: [swift-evolution] Allow a typealias to be named after the corresponding type

This doesn’t work if `DataStructureKit` and `BinarySearchTree` have the same name. > > public struct BinarySearchTree{ > > typealias Node = Node > > var root: Node? > > } > > > > private class Node{ } > > > > This code currently doesn’t compile because the Node typealias circularly

[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

I heard that this has been brought up before, but what if we give all non-mutating methods the same name as their mutating counterparts? The compiler can just pick the right one based on whether an assignment is taking place or not. Here are the advantages I can think of: - it would end this

[swift-evolution] Allow a typealias to be named after the corresponding type

public struct BinarySearchTree { typealias Node = Node var root: Node? } private class Node { } This code currently doesn’t compile because the Node typealias circularly references itself. I’d like this syntax to just work, because this are the alternatives: - rename the

Re: [swift-evolution] Add a while clause to for loops

It’s funny that you use this example as an argument against this proposal, because what led me to propose the `while` clause in the first place was a very similar incident (but instead of using `where` expecting it to terminate early, I tried to use a `while` clause, not immediately realising

Re: [swift-evolution] Add a while clause to for loops

and is the most general, I would oppose > adding the option of `while` to offer more choice. > > > > > >On Wed, Jun 8, 2016 at 1:35 PM, Tim Vermeulen via > > >swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-ev

Re: [swift-evolution] Add a while clause to for loops

I’m not sure I follow, how would the two be different? > There might be value in entertaining the idea of unifying constructs such > that they all allow arbitrary combinations of for/while/where/etc. > > Such as: > > while !stopped for unit in workToDo where unit.passesTest(condition) { >

Re: [swift-evolution] Add a while clause to for loops

gt; >>>``` > > >>>for foo in bar where condition1 while condition2 { ... } > > >>>``` > > >>> > > >>>If condition1 and condition2 both evaluate to true, then whether you > > >>>continue or break w

Re: [swift-evolution] Add a while clause to for loops

for generality, you would want to allow both `for...in...where...while` > > > and `for...in...while...where`, and likely > > > `for...in...while...where...while`, etc. There is nothing in the meaning > > > of those words that would suggest that `while...where` behaves &

Re: [swift-evolution] Add a while clause to for loops

> Why would breaking from a loop intuitively use a place analogy and continuing > to the next iteration use a time analogy? This is totally made up; hence, it > is not intuitive. I make no argument about whether or not it would be > conceptually confusing. If you renamed 'break' to 'foo' and

Re: [swift-evolution] Marking sort and sorted with rethrows

Of course, on performance of the normal case should never be compromised. So if making two overloads is the only way to ensure that, then that’s what it takes. But will the performance of the normal case really suffer if we only require a sorting algorithm to restore the array to an arbitrary

Re: [swift-evolution] Add a while clause to for loops

`, etc. There is nothing in the meaning > > >of those words that would suggest that `while...where` behaves differently > > >from `where...while`, etc. This is why words like "break" and "continue" > > >are IMO far superior. > > > > > > &

Re: [swift-evolution] Add a while clause to for loops

feel familiar with it. > > On Jun 7, 2016, at 1:16 PM, Tim Vermeulen via > > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote: > > > The meaning of the proposed while is not at all a pair for where, since > > > where clauses in

Re: [swift-evolution] Add a while clause to for loops

words like "break" and "continue" are IMO far superior. > > > On Tue, Jun 7, 2016 at 2:34 PM, Erica > Sadun<er...@ericasadun.com(mailto:er...@ericasadun.com)>wrote: > > > > > On Jun 7, 2016, at 1:16 PM, Tim Vermeulen via > >

Re: [swift-evolution] Add a while clause to for loops

stinct enough, and actually in my code I’m probably more likely > > to use while than where on for loops, although both are useful. > > > > >On 6 Jun 2016, at 11:15, Tim Vermeulen via > > >swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)&

Re: [swift-evolution] Add a while clause to for loops

ift-evolution@swift.org > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > >><mailto:swift-evolution@swift.org>)>wrote: > > >>>>>>(As I said, I can live with `while`. I am simply presenting a > >

Re: [swift-evolution] Marking sort and sorted with rethrows

rror is thrown. > > > On Mon, Jun 6, 2016 at 5:31 PM Dave Abrahams via swift-evolution< > > swift-evolution@swift.org>wrote: > > > > > > > > on Sun Jun 05 2016, Haravikk<swift-evolution@swift.org>wrote: > > > >

Re: [swift-evolution] Add a while clause to for loops

t time that the condition isn't met, > > > >>>>evaluation of the loop stops. I get that this is technically true for > > > >>>>the `while` construct but I suggest that the only reason that it > > > >>>>works there is that 'stopping the first

Re: [swift-evolution] Add a while clause to for loops

e only reason that it works there is that 'stopping > > >>the first time that the condition isn't met' *is* the construct. Here, we > > >>have a loop that we execute for each thing and we're tacking > > >>on/intermingling the `while` construct. > > >&

Re: [swift-evolution] [Proposal] A more liberal placement of defer

>And simple functions like fibonacci I would just write without using `defer` >at all - it's just confusing to use `defer` and `inout` in this case IMO. > > /// Calculates the n'th fibonacci number. (n>= 1) > func fibonacci(n: Int) ->Int { > var a = 0 > var b = 1 > for _ in 1...n { > (a,b)=(b,

Re: [swift-evolution] Add a while clause to for loops

struct. > > > > > > > > On Mon, Jun 6, 2016 at 2:19 PM, Thorsten > > Seitz<tseit...@icloud.com(mailto:tseit...@icloud.com)>wrote: > > > > > > >Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via > > > >swift-evolution<swift-evolut

Re: [swift-evolution] Add a while clause to for loops

should do what `where` does. In > any case, whether it is `while` or `where`, this seems like a reasonable > feature in my opinion. > > TJ > > On Mon, Jun 6, 2016 at 5:15 AM, Tim Vermeulen via > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.o

[swift-evolution] Add a while clause to for loops

We can already use a where clause in a for loop like this: for element in array where someCondition(element) { // … } which basically acts like for element in array { guard someCondition(element) else { continue } // … } Sometimes you want to break out of the loop when the

[swift-evolution] Marking sort and sorted with rethrows

Most standard library functions that take a closure allow that closure to throw (and those functions are subsequently marked with rethrows). sort and sorted are exceptions to this. I couldn’t find this documented anywhere, but I assume this is because sorting can happen in-place and it would be

[swift-evolution] Allow partial applications of mutating methods in @noescape contexts

struct MyStruct { var count = 0 mutating func add(amount: Int) { count += amount } } var myStruct = MyStruct() [1, 2, 3, 4].forEach(myStruct.add) This code currently doesn’t compile because myStruct.add is a partial application of a mutating method, which is forbidden.

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

> I don't think I have ever mapped keys. Incidentally, that doesn't have the > usual semantics of a map operation as you can produce duplicate keys. As has been pointed out in other messages here, the slight change I suggested would let you see the key when mapping the value, but it wouldn’t

[swift-evolution] [Pitch] Add `mapValues` method to Dictionary

I really like this idea, because indeed this wasn’t possible functionally before. I have a small remark though, wouldn’t it be better to let transform be of type (Key, Value) throws -> T instead of (Value) throws -> T? You can just ignore the key (with _) if you don’t need it, but I think it

[swift-evolution] [Pitch] 'Double modulo' operator

+1, I’ve never actually wanted a negative return value from %. Array subscripting and getting an enum case from a raw integer value both expect non-negative integers, so in these cases it only makes sense to deal with positive values. > Hello, > > I think that Swift could use the 'double

[swift-evolution] Add a stride(by:) method to ClosedRange

If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can change stride(from: 0, to: 10, by: 3) to (0..<10).stride(by: 3) and similarly, we can change stride(from: 0, through: 10, by: 3) to (0…10).stride(by: 3) As we can see, this syntax can replace both stride(from:to:by:)

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The idea of distinguishing all mutating/non-mutating functions with only the > assignment operator did occur to me as I wrote that. > Using such a rule would allow automatic generation of mutating methods from > non-mutating ones, since the naming would no longer need changing. > However, this

Re: [swift-evolution] Properties with parameters

> Tim Vermeulen via swift-evolution<swift-evolution@...>writes: > > > Properties are great. They allow us to write the more naturally looking > > > > myButton.hidden = true > > > > instead of > > > > myButton.setHidden(true) > > >

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The whole naming issue seems to be caused by the .union(_:) function. The > Swift Guidelines say that mutating functions should use a verb, and > non-mutating forms should use a noun, but in this case, the word union itself > is a verb and a noun. > > Have we considered this, then: > >

[swift-evolution] Properties with parameters

Properties are great. They allow us to write the more naturally looking myButton.hidden = true instead of myButton.setHidden(true) However, they don't take any parameters. That’s why we still have to write myButton.setImage(myImage, forState: .Normal) instead of