Re: [swift-evolution] [Idea] Generic subscripts

> * Who is interested in this feature? Me definitely, everyone probably. > * Should it be severed from throwing subscripts? That depends I guess; subscripts are basically functions anyway so it didn't make a lot of sense to me that they lacked features that functions have, so if implementing

[swift-evolution] [Pre-proposal/Discussion] Padding and Smaller Integer Types?

So we have a pretty good set of integer types right now, but one issue I come into is when they don't quite fit within the padding of a type. It's not something I've ever really thought about before, since most of my background is in OOP with reference types (Java for example) and these don't

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

> On 1 Aug 2016, at 21:40, Charlie Monroe <char...@charliemonroe.net> wrote: > >> >> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On 1 Aug 2016, at 19:05, Goffredo Marocchi v

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

> On 1 Aug 2016, at 19:05, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > >> On 31 Jul 2016, at 21:19, Sean Alling via swift-evolution >> wrote: >> >> I disagree with this suggestion. Both a protocol

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

But I like sending out my messages then regretting the many typos and mistakes I only seem able to notice immediately after it's too late to do anything about it! (so yeah, +1) > On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution > wrote: > > +1 to

Re: [swift-evolution] Improved value and move semantics

> On 29 Jul 2016, at 17:42, Bram Beernink via swift-evolution > wrote: > > Hi all, > > Would it be possible to improve value and move semantics (performance) in > Swift? Consider this possible Swift code in a future release of Swift: > > let array1 : [String] =

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

This is very interesting, but it'll probably be a little while before I can fully get my head around it. One query though; an example mentioned is adding @owns(Element) to the Generator protocol, but associated types feel a little different to me; you mention using the strong keyword as an

Re: [swift-evolution] [Proposal] Variadics as Attribute

Hate to have to bump this myself, but I'm still hoping to get more detailed feedback from those that have made negative comments to clarify or clear up any misunderstandings. So far the main argument made against the change is that it's more complex than the problem being solved, however this

Re: [swift-evolution] [Review] SE-0130: Replace repeating Character and UnicodeScalar forms of String.init

> On 22 Jul 2016, at 21:23, Chris Lattner via swift-evolution > wrote: > * What is your evaluation of the proposal? I think I'm generally in favour (see later). > * Is the problem being addressed significant enough to warrant a change > to Swift? It's

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Definitely a +1 from me, in fact I've implemented essentially this as an extension for my own convenience, but would definitely prefer it to be a proper component of the stdlib. I have some queries to raise: First is the naming, to me Ordering implies the enum itself is used for ordering

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 21 Jul 2016, at 23:05, Tino Heth <2...@gmx.de> wrote: >> Am 21.07.2016 um 22:11 schrieb Haravikk > >: >> it also opens passing of arrays to variadic functions, which seems to be >> fairly desired despite no proposal that I

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 20 Jul 2016, at 20:54, Chris Lattner <clatt...@apple.com> wrote: > > >> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On 20 Jul 2016, at 14:55, Tino Heth <2...@gmx

Re: [swift-evolution] Returning nothing

> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution > wrote: >> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution >> wrote: >> >> This may be a silly question - given that one of Swift’s design principles >>

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 20 Jul 2016, at 21:25, Leonardo Pessoa wrote: > > I'm strongly opposed to this too. I'm not only not fond of the > proposed syntax but I also don't really see how allowing other types > in variadics will help anything. Also, there may be necessary more > complex code to

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 20 Jul 2016, at 14:55, Tino Heth <2...@gmx.de> wrote: > > >> Am 17.07.2016 um 18:31 schrieb Haravikk : >> >> I may move discussion of other collection types to its own section though, >> to make the core proposal as simple as possible, and leave it up to the

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? I'm leaning towards in favour, but very marginally as to be frank I'm not that bothered either way. The subscript is a definite hybrid of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

> On 20 Jul 2016, at 11:13, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 19, 2016, at 11:06 PM, Dmitri Gribenko via swift-evolution >> wrote: >> >> - I find it a little strange to see a mention of Objective-C, and a >>

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

> On 18 Jul 2016, at 21:32, Sean Heber via swift-evolution > wrote: > > I’ve wanted this myself, too, so I’m generally +1, although I’ve also > wondered if maybe this syntax should be changed somehow. I’ve not put a lot > of thought into it, and this perhaps has

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

Strong +1 from me, I actually ran into a bunch of cases like this recently, having to put a tracking variable outside the loop feels weird; it makes sense for a regular while loop, but I see no reason that repeat/while couldn't have values from the loop be in scope for its condition. There is

Re: [swift-evolution] [Discussion] Additional generics specialization

> On 18 Jul 2016, at 08:04, Adrian Zubarev via swift-evolution > wrote: > > This is something additional, but I’m curios about how the community feels > about it. > > I recently come across the issue where conforming to Hashable wasn’t enough > to thecke if two

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 15 Jul 2016, at 20:14, Tino Heth <2...@gmx.de> wrote: > > The last post in this thread is nearly a week ago... did you already apply > for review? > It would be a pity if this topic isn't finished, and I think a reduced > variant that merely replaces "values: Int…" with "@variadic _

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

> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution > wrote: > > To sum this all up, the core team is rejecting this proposal and requesting a > revision to change the concrete syntax to “public open class Foo” instead of > “subclassable class Foo".

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

> On 12 Jul 2016, at 19:26, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? Strongly in favour. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, though it seems like a

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

> On 11 Jul 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > > > on Sat Jul 09 2016, Karl > wrote: > >>> On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I'm a bit undecided about this feature, as I think it's harder to read the switch statement. For example, with this new feature I could write something like so: switch x { case 1: print("1") case 2:

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 8 Jul 2016, at 21:18, Kristóf Liliom wrote: > > I read through this proposal, and I have the feeling that we are trying to > solve an issue with Swift from the wrong angle. IMHO Swift has one of the > best implementations of variadics which has only one major

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 8 Jul 2016, at 12:03, Leonardo Pessoa wrote: > You would have to add some extra code on the compiler to check whether you > can use that type for your variadics argument and may incur in more changes > to enable handling different classes possible. Not really; the

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 8 Jul 2016, at 10:31, Pyry Jahkola wrote: > > If you take this function for example, > > func printThem(@variadic _ values: [Any]) > > then what would `values` be in the following calls, and why? > > printThem() // clearly [] > printThem(1) // clearly

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 7 Jul 2016, at 22:39, Leonardo Pessoa wrote: > > I think we'd have less effort (and less breaking more > backward compatibility) if we just allow variadic arguments to receive > arrays of its type directly. This proposal doesn't just handle the issue of passing an array

[swift-evolution] [Proposal] Variadics as Attribute

Posted a new proposal, feedback appreciated: https://github.com/Haravikk/swift-evolution/blob/2743411af02e3ac6761fbdd780ede1af4cc34ee7/proposals/-variadics-as-attribute.md One talking point raised already is the correct location for the attribute (parameter or type); I'm undecided

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

> On 7 Jul 2016, at 21:07, G B via swift-evolution > wrote: > > It has always seemed odd to me that `case`s use a colon as a delimiter rather > than curly braces like everything else. Is there a reason for this other > than the legacy of C-like languages? > >

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On 7 Jul 2016, at 19:41, David Sweeris via swift-evolution > wrote: > > >> On Jul 7, 2016, at 12:58, Vladimir.S via swift-evolution >> wrote: >> >> I didn't expect this is allowed(with warning): >> >> try print("foo") >> >> (Swift

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

> On 7 Jul 2016, at 15:57, Karl via swift-evolution > wrote: > > I believe the idea of RRC is that all you need to implement is the empty > initialiser and replaceSubrange(), and everything else (e.g. Append, insert) > is implemented in terms of those. Even the

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

I'm very much in the camp that doesn't mind breaking changes; of course we shouldn't be too cavalier about them either, but if a sound case can be made for why a breaking change is required, then we shouldn't be afraid to make the change either. The biggest example that's impacted me in Swift

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

> On 7 Jul 2016, at 06:50, Tim Vermeulen via swift-evolution > wrote: > > 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

Re: [swift-evolution] Removing Variadic Parameters.

> On 6 Jul 2016, at 21:13, David Rönnqvist via swift-evolution > wrote: > > 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

Re: [swift-evolution] Dropping Comparable requirement for indices

> On 7 Jul 2016, at 02:41, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jul 06 2016, Haravikk wrote: > >>> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution >>> wrote: >>> For example,

Re: [swift-evolution] Dropping Comparable requirement for indices

> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution > wrote: > For example, with > Comparable indices, you can't build a linked list that supports > restructuring (e.g. insert, delete, splice) in O(1) without invalidating > indices... not even an unsafe linked

Re: [swift-evolution] Public classes with private superclass

> On 5 Jul 2016, at 08:01, Charlie Monroe via swift-evolution > wrote: > > IMHO these things can be solved by private protocols with default > implementation to reuse the code: > Or you can just create a private class and use its instance in your classes: The other

Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

There was a proposal a little while ago to change Comparable to have an operator producing an enum (with ordered before, same and ordered after cases) which provides strict ordering requirements (unlike the current comparable methods). I think this would serve as a better basis for replacing

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> On 3 Jul 2016, at 20:03, Vladimir.S wrote: > > But, then, regarding the consistency and confusion, I have a question: is it > expected that func f() {..} will *return* `Void` ? I believe it is not > expected exactly at the same level as Void in parameter for 0 argument >

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> On 3 Jul 2016, at 13:02, Vladimir.S via swift-evolution > wrote: > > On 02.07.2016 4:20, Daniel Duan via swift-evolution wrote: >>> Vladimir.S via swift-evolution writes: >> >> Following your conclusion, should this be legal as well? >> >>

Re: [swift-evolution] Proposal: Remove the underscore and `in`for `for` loop

> On 2 Jul 2016, at 14:19, Anton Zhilin via swift-evolution > wrote: > > Diego Barros via swift-evolution writes: > >> for 1...10 { >> // do something 10 times >> } > > Firstly, this should be delayed to post-Swift 3. > Secondly, I tend to

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 30 Jun 2016, at 23:39, Dave Abrahams wrote: > All multi-pass sequences can benefit from subscripts. Sorry, not really what I meant, but rather; how many sequences are really going to use them? > It's trivial; the index contains the iteration state. The only >

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 30 Jun 2016, at 18:26, Dave Abrahams wrote: > > Q: Why should there be indices on an infinite multipass sequence? > A: Because the operations on indices apply equally well whether the > sequence is finite or not. Find the index of a value in the > sequence,

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

> On 30 Jun 2016, at 11:22, Adrian Zubarev via swift-evolution > wrote: > It is an interesting suggestion to use extensions that way, but how would you > nest and create diffrent label pathes with extensions? > > We also cannot nest extensions (yet) and when it

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 28, 2016, at 3:33 PM, Brent Royal-Gordon >> wrote: >> >>> This use case seems interesting enough to at least deserve some >>> consideration before we

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

> On 27 Jun 2016, at 11:00, Manuel Krebber via swift-evolution > wrote: > > Hi everyone, > > I was thinking it would be nice to have a similar short notation for > using methods in a functional way as there is for enum cases (and as > I've been told static members

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

I'm a tentative +1, but I think we might consider a degree of "sealing", e.g- make extending the type a warning rather than an error, or require an attribute in order to force the extension. In other words, we make it perfectly clear that extending anyway is a bad idea, but still allow it to be

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 27 Jun 2016, at 04:56, Jonathan Hull via swift-evolution > wrote: > > Can’t a Sequence be potentially infinite, whereas a collection has a defined > count/endIndex? Other than that, I agree with your statement. > > Here is what I see as the appropriate

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

+1 to this; I seem to keep running into cases of this, and it crops up especially when Swift is having difficulty inferring a type, which can be tricky to debug as it is, so I think it's better to just be consistent and explicit, with double brackets for all tuple type closures as proposed. >

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 27 Jun 2016, at 07:55, James Hillhouse wrote: > >> >> On Jun 27, 2016, at 1:53 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I disagree: in English, the nouns are floor and ceiling. That's what

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 25 Jun 2016, at 11:06, Karl via swift-evolution > wrote: > > floor() and ceil(), exactly like C. ceiling() is more descriptive and is a > mathematical term of art . > nextIntegralUp() and nextIntegralDown() are

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

> On 24 Jun 2016, at 23:38, William Jon Shipley <w...@delicious-monster.com> > wrote: > >> On Jun 24, 2016, at 3:00 PM, Haravikk via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> f

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

> On 24 Jun 2016, at 22:33, Erica Sadun via swift-evolution > wrote: > > most of these read as if there is too much logic stuffed into a single line: > >> for otherWall: Wall in self where otherWall != wall && >> !removedWalls.contains(otherWall) { >> >>

Re: [swift-evolution] Collection index complexity and data structures

I started a discussion thread that may be of interest to you, basically discussing the possibility for directional methods to reduce confusion/clarify intent, should be accessible at the following URL: http://thread.gmane.org/gmane.comp.lang.swift.evolution/19185/focus=19613 > On 24 Jun 2016,

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution > wrote: > I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which > will likely lead to a measurable speedup. Why is there no > `doubleWidthQuotientAndRemainder` or

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

This is an interesting thing to consider, as the current auto-complete seems to favour whitespace on both sides, but I actually use it differently depending upon context. For specifying type I use no whitespace, but for inheritance/conformance I use whitespace on both sides, so for me it's:

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

> On 22 Jun 2016, at 09:39, Goffredo Marocchi via swift-evolution > wrote: > > Sorry, but can you explain why the character used to escape strings is > also the best choice to do Variable value extraction/String interpolation? > They are two different

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

> On 21 Jun 2016, at 22:49, Gwynne Raskind via swift-evolution > wrote: > >> On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution >> > wrote: >> >> I'd support $() as is in use by other

Re: [swift-evolution] [Pitch] remove(at: Set)

> On 19 Jun 2016, at 11:12, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote: > > I think the following should work for the generic case, and is pretty similar: > > extension MutableCollection { > public mutating func remove(indices: Set)

Re: [swift-evolution] [Proposal] Fix lazy filter

> On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution > wrote: > > > on Sun Jun 19 2016, Kevin Lundberg wrote: > >> this seems more like a bug fix to me than a language change. Does it >> need to go through evolution? > > It's

Re: [swift-evolution] [Pitch] remove(at: Set)

> On 19 Jun 2016, at 05:58, Saagar Jha via swift-evolution > wrote: > > This isn’t actually that complex, especially if you ditch the “C-style” for > loop algorithm and switch it to, as you mentioned, “filtering code”. filter, > enumerated (to get indices), and map

Re: [swift-evolution] API Guidelines: dropFirst?

> On 16 Jun 2016, at 08:39, Brent Royal-Gordon via swift-evolution > wrote: > >> What is the rationale behind the name dropFirst()? Being a non-mutating >> method it should clearly be e.g. droppingFirst() according to the API Naming >> Guidelines. > > Like many

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

> On 15 Jun 2016, at 09:35, Brent Royal-Gordon via swift-evolution > wrote: > >> public struct BinarySearchTree { >>typealias Node = Node >>var root: Node? >> } >> >> private class Node { } >> >> This code currently doesn’t compile because the

Re: [swift-evolution] Nil coalescing operator precedence

> On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution > wrote: > I don't know that it's feasible to warn on every use of operators with mixed > precedence. Doing so would effectively do away with the concept of precedence > at all, since everything would have to

Re: [swift-evolution] Nil coalescing operator precedence

> On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution > wrote: > I don't know that it's feasible to warn on every use of operators with mixed > precedence. Doing so would effectively do away with the concept of precedence > at all, since everything would have to

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 15 Jun 2016, at 03:43, Jo Albright wrote: > > This is probably going to get lost in this massive chain. But I am going to > try to throw out a solution that I am not currently finding in this > conversation. > > There is a huge battle between removing and keeping keywords

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 14 Jun 2016, at 07:54, Xiaodi Wu via swift-evolution > wrote: > > And a language feature being undocumented wouldn't explain why the entire > stdlib uses it only three times :) I sometimes wonder whether the stdlib is always the best example of pure Swift

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution > wrote: > > I think this discussion has made it pretty plain that what is claimed to be > 'so useful' is barely ever used. Moreover, it provides no independent uses. > The point of these pitches is to sound

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

> On 13 Jun 2016, at 15:52, Erica Sadun wrote: > > I'm not sure what enhancing defaults would look like, especially for > protocols. Are you suggesting if there's a protocol like: > > protocol A { >func requiredFunction(a, b, c) -> T > } > > that you could then

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

As Charlie says the default value may not actually be public. There was a thread a while ago about allowing defaults to be defined in protocols, but I don’t think it ever got made into a proposal; this would be useful however in cases where you want a consistent, known default. Either that or

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

+1 from me; I never considered that I could do this using pattern matching of a tuple, and as Brent says this is a nicer shorthand for introducing users to conditional binding in advance of teaching the finer details of pattern matching, plus I prefer it visually. > On 12 Jun 2016, at 12:46,

Re: [swift-evolution] [Proposal] Add support for compile-time function execution

> On 12 Jun 2016, at 09:47, L Mihalkovic via swift-evolution > wrote: > > >> On Jun 12, 2016, at 6:05 AM, Alexander Momchilov >> > wrote: >> >> Aren't macros totally different? >> >> Anyways,

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On 10 Jun 2016, at 21:15, Thorsten Seitz via swift-evolution > wrote: > > -1 > >> Am 10.06.2016 um 21:10 schrieb Brent Royal-Gordon via swift-evolution >> >: >> >> if case .some(let Point.cartesian(x,

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 10 Jun 2016, at 21:53, Xiaodi Wu wrote: > > I had quite a visceral reaction to the example given at one point: > > for number in fibonacci where number % 2 == 0 while number < 4_000_000 {...} > > This, IMO, is long enough to cause a heart attack. This is not what’s

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 10 Jun 2016, at 20:45, Xiaodi Wu wrote: > > I'm sorry, but until this discussion I had never heard of a coding style that > advocates for conservation of vertical space. There's a lot of argument > whether 80 characters is still a relevant line length, but I've never

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 10 Jun 2016, at 19:10, Xiaodi Wu via swift-evolution > wrote: > So "inessential" alone is not a good sole criterion--I agree. But it is one > of several prongs here: `where` is not only inessential, I argue that it > lacks expressiveness (in that what is

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution > wrote: > * Swift is explicitly a C-family language. In most or all other C-family > languages, for loop statements allow specification of conditions for exiting > the loop but not for filtering. Therefore,

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

I think the idea here is for a change from the first to the second of: for eachValue in theValues where eachValue.isOdd { … } for eachValue where eachValue.isOdd in theValues { … } I’m kind of split on this for a few reasons. The first is that it doesn’t ready quite as well

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

> On 9 Jun 2016, at 17:11, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Haravikk > wrote: > >>> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution >> > wrote:

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On 9 Jun 2016, at 09:47, Brent Royal-Gordon wrote: > >> Can we get some clarification as to why ‘where’ is being chosen to be >> retired here? I’m deeply disappointed by that decision as enabling the >> consistent use of comma as a separator does not preclude the use

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On 9 Jun 2016, at 09:47, Brent Royal-Gordon wrote: > >> Can we get some clarification as to why ‘where’ is being chosen to be >> retired here? I’m deeply disappointed by that decision as enabling the >> consistent use of comma as a separator does not preclude the use

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution > wrote: > >> on Wed Jun 08 2016, Haravikk > > wrote: >> >> But those shouldn't be the public names. Perhaps s/box/wrap/ ? True! So I’m

[swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

So I’m working on a kind of collection wrapper, and hoping to avoid having to expose the underlying type of the collection, by instead returning indices of AnyIndex. This works fine in one direction, but when it comes time to actually use these I have no means of unwrapping them into their

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

> On 8 Jun 2016, at 01:54, Xiaodi Wu via swift-evolution > wrote: > > 1) It is spelled out exactly what happens when a condition is met. I no > longer have to remember whether the word that describes breaking from a loop > uses a place analogy ("where") or a time

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

While I can kind of see where you’re coming from I’m not sure about the change; the key thing about defer is that it doesn’t just execute in the cases you explicitly define, but can also occur if exceptions are thrown and other exit cases that could be all over the scope. To compare with other

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

> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

> Am 31.05.2016 um 14:46 schrieb Haravikk via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: > >> So for Swift 3 we’re going to have the great new indexing model that >> performs index manipulation through the collection to wh

Re: [swift-evolution] Ad hoc enums / options

> On 1 Jun 2016, at 12:35, Leonardo Pessoa wrote: > > Unions have been discussed earlier in this group and I personally > think this is an issue better solved using function overloading. Sorry, my intention wasn’t to debate them, I was just using them as an example of a

Re: [swift-evolution] Ad hoc enums / options

I agree the second is much nicer, and a lot clearer on what each of the options does; fitImage: true is pretty clear, but fitImage: false is not, but the ad-hoc enum is clear on both counts. That said, the questions of interoperability are a big issue for ad-hoc enums, as either they’re too

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

> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution > wrote: > > Q: How is an arbitrary boolean assertion introduced after `if let`? > > Option 1 (present scenario)--using `where` > Advantages: expressive when it means exactly the right thing > Drawbacks: makes

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

I’m a +1 for making the behaviour more consistent, I can’t imagine many people rely on the guaranteed execution for static properties (personally I wasn’t even aware there was a difference), and anyone that needs guaranteed execution should be implementing lazy properties manually (i.e- with

[swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

So for Swift 3 we’re going to have the great new indexing model that performs index manipulation through the collection to which an index belongs. However, it retains one of the things I didn’t like about the old model, which is that the distinction between forward/backward only types is a bit

Re: [swift-evolution] [Discussion] Type for matching a closure

I’m a +1 for being able to detect them, a protocol would also be useful for defining methods and such on them in future. I’m curious why you’re hoping to deny functions in your example though; there’s nothing you can really do with T without testing/casting it, in which case a default case or

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

> On 29 May 2016, at 20:39, Chris Lattner wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk > > wrote: On May 27, 2016, at 12:11 PM, Joe Groff > wrote:

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

> On 28 May 2016, at 23:48, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition Clauses”

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

ection you use later. More complex generics definitely need to be explored separately, but Sequence.of should be just as simple to use as [Foo], it’s just a little longer because of the ability to distinguish between sequence and collection. > On Sat, May 28, 2016 at 14:38 Haravikk v

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

> On 28 May 2016, at 20:21, Xiaodi Wu wrote: > > There's already an inconsistency in where clause behavior for `if` and > `while` versus `for` loops. It's nice IMO that the former uses are eliminated > in this proposal. Can you give an example? That sounds like something

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

> On 27 May 2016, at 20:11, Joe Groff via swift-evolution > wrote: > > • What is your evaluation of the proposal? Uncertain. I understand the intent behind it, but personally I really like the where clause as it covers most cases where I need to mix and match,

<    1   2   3   4   5   >