Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-06 Thread Xiaodi Wu via swift-evolution
>Possible solution: if you want a new protocol adoption to map to some existing >method or property then you must explicitly write that. You can't just adopt >the protocol in an empty extension. > >extension Int: BoundedType { >static var min = Int.min >static var max =

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-06 Thread Xiaodi Wu via swift-evolution
t coder who intended to supply a default function but invoke any overriding methods could write code that is almost as succinct but also self-documenting, and in fact could do so today. On Wed, Jan 6, 2016 at 12:45 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > > Am 06.01.2016 u

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-06 Thread Xiaodi Wu via swift-evolution
-expert coder could try > to formalize after the fact and write an extension BooType > implementing boo() unaware that there is an overriding method in Foo. > In today's Swift syntax, the code would compile and behave subtly > differently from the author's expectations; as proposed, that co

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-05 Thread Xiaodi Wu via swift-evolution
> This has been suggested before, usually in the form of a separate `implement` keyword. The main problem is that it makes it impossible to write a protocol after the fact which formalizes some existing pattern in the types. I think this is a great point and would be a con that I hadn't

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-06 Thread Xiaodi Wu via swift-evolution
Lovatt <howard.lov...@gmail.com> wrote: > Comments in-line below. > > > On Thursday, 7 January 2016, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: >> >> > Another option might be to allow imported definitions to be used by a >> > conformanc

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

2016-06-02 Thread Xiaodi Wu via swift-evolution
Nope. I use it with Metal buffers, for example :) Moreover, there's nothing inherently unsafe about sizeof, and I think it's important, *especially when you're working with UnsafePointers*, that safe things look safe. If the moment a pointer comes into the picture everything related to it is

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

2016-06-02 Thread Xiaodi Wu via swift-evolution
ort. These values are specialized; we don't need > to optimize typing them, IMO. > > On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution < >> swift-e

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

2016-06-02 Thread Xiaodi Wu via swift-evolution
See, I've made this mistake as well, and *not* because I thought it casts the literal. I had always assumed that something like `UInt16(42)` would initialize using the integer literal init, since it seems logical that that's the most specific. The proposed change reflects my currently erroneous

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

2016-06-02 Thread Xiaodi Wu via swift-evolution
On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > I still think the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

2016-06-02 Thread Xiaodi Wu via swift-evolution
Isn't this the same argument for .dynamicType over type(of:) though? Given that that debate has been settled in favor of the latter, I think the question today is how best to come up with a consistent scheme. Earlier in this conversation, it was pointed out (by Matt, I think?) that one key

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

2016-06-02 Thread Xiaodi Wu via swift-evolution
The IntegerLiteral type idea might be worth exploring. It does seem to provide some additional consistency. For example, wasn't it clarified on this list just recently that literals don't have a type and adopt one based on context? It'd be nice to point out that 42 is an IntegerLiteral when

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

2016-06-02 Thread Xiaodi Wu via swift-evolution
2, 2016 at 19:53 Matthew Johnson <matt...@anandabits.com> wrote: > > > Sent from my iPad > > On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On the other hand, on its own sizeof() is not unsafe, and so the

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

2016-06-03 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 3, 2016 at 2:41 PM, Matthew Johnson wrote: > > On Jun 3, 2016, at 1:36 PM, John McCall wrote: > > On Jun 2, 2016, at 6:48 PM, Matthew Johnson > wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution <

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
On Wed, Jun 8, 2016 at 3:38 AM, Haravikk <swift-evolut...@haravikk.me> wrote: > > On 8 Jun 2016, at 01:54, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > 1) It is spelled out exactly what happens when a condition is met. I no > longer hav

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
= fibonacci.prefix { veryExpensiveTest($0) } > for number in numbers where number % 2 == 0 {} > > So, `while` for `for` loops just can't be always replaced with `prefix` > > On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote: > > On Tue, Jun 7, 2016 at 5:11 PM, Tim Vermeulen <tvermeu

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
On Wed, Jun 8, 2016 at 1:51 PM, Jacob Bandes-Storch wrote: > On Wed, Jun 8, 2016 at 1:38 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’m not sure I agree that this is confusing, a little extra to learn for >> new programmers perhaps but I think

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
here number % 2 == 0 while > > > >veryExpensiveTest(number) {} > > > > > > > >let numbers = fibonacci.prefix { veryExpensiveTest($0) } > > > >for number in numbers where number % 2 == 0 {} > > > > > > > >So, `whil

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
On Wed, Jun 8, 2016 at 2:31 PM, Erica Sadun <er...@ericasadun.com> wrote: > > > On Jun 8, 2016, at 1:07 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I should add, on the topic of removing `where`, there would be a higher > threshol

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
gt; >by `number % 2`. Let's assume we need to check for some >> > > >veryExpensiveTest(number): >> > > > >> > > >for number in fibonacci where number % 2 == 0 while >> > > >veryExpensiveTest(number) {} >> > > > >> > > >let

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
which is fine. > > > On Wed, Jun 8, 2016 at 3:38 AM, Haravikk<swift-evolut...@haravikk.me > (mailto:swift-evolut...@haravikk.me)>wrote: > > > > > > > On 8 Jun 2016, at 01:54, Xiaodi Wu via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolu

Re: [swift-evolution] Remove nil and NilLiteralConvertible

2016-06-08 Thread Xiaodi Wu via swift-evolution
liberate choice to allow progressive disclosure of the language to learners. Renaming `nil` to `none` is a different proposal from Anton is proposing here. > Brandon > > On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > It's been

Re: [swift-evolution] Remove nil and NilLiteralConvertible

2016-06-08 Thread Xiaodi Wu via swift-evolution
liberate choice to allow progressive disclosure of the language > to learners. Renaming `nil` to `none` is a different proposal from Anton is > proposing here. > > >> Brandon >> >> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution < >> swift-evolution

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

2016-06-08 Thread Xiaodi Wu via swift-evolution
er` and only after this > filtered > > > >>>by `number % 2`. Let's assume we need to check for some > > > >>>veryExpensiveTest(number): > > > >>> > > > >>>for number in fibonacci where number % 2 == 0 while > > >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 3:57 PM, wrote: > > > Am 07.06.2016 um 22:36 schrieb Charles Srstka via swift-evolution < > swift-evolution@swift.org>: > > > >> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > >> > >> On Tue, Jun 7, 2016 at 2:49 PM, Michael

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 6:26 PM, Tim Vermeulen wrote: > Interesting. What if you put newlines before `where` and `while`? It’s > hard to get the spacing right in a mailing list, but I tried it in Xcode > and it looks really good to me (except for the compiler error it currently

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 3:36 PM, Charles Srstka wrote: > On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > > > On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > Am 07.06.2016 um 19:45

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution < > swift-evolution@swift.org>: > > > >> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution < >

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 2:39 PM, Tim Vermeulen wrote: > > `while let element = sequence.next() where condition {…}` > > This is not a good alternative. First of all, it uses `while let` and > `next()` instead of `for … in` which is way more complex than necessary. > Also, if we

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
It may be workable if you can have only one or the other, but mixing and matching them as proposed above would be a world of hurt: ``` for foo in bar where condition1 while condition2 { ... } ``` If condition1 and condition2 both evaluate to true, then whether you continue or break would depend

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
On Tue, Jun 7, 2016 at 5:11 PM, Tim Vermeulen wrote: > I’ve been thinking about this for a bit now, and I think it would make > most sense to evaluate these clauses from left to right. However, cases > where the order matters are very uncommon, and I would rather have the >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

2016-06-06 Thread Xiaodi Wu via swift-evolution
On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > I'd argue that it's more important for the language to be clearly readable > than to satisfy a notion of absolute adherence to pure formal semantics > that only theorists would completely

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
> > } > > > > or > > > > for result in results { > > if result.value == .Warning { continue } > > if result.value == .Error { break } > > > > /// ... > > } > > > > Seems like an absolute step back. Not to mention filter(_:) do

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

2016-06-07 Thread Xiaodi Wu via swift-evolution
You're describing a while loop: `while let element = sequence.next() where condition {...}` Which as we've discussed can already be re-written with a for loop (which, yes, can be lazy): `for element in sequence.lazy.filter({ condition }) {...}` And it can be explicitly spelled out inside the

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

2016-06-06 Thread Xiaodi Wu via swift-evolution
The functionality being asked for here is already accepted for inclusion to Swift as a method on Sequence named `prefix(while:)` (SE-0045): `for element in array.prefix(while: { someCondition($0) }) { ... }` On Mon, Jun 6, 2016 at 14:31 T.J. Usiyan via swift-evolution < swift-evolution@swift.org>

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

2016-06-06 Thread Xiaodi Wu via swift-evolution
The burden of proof for adding new features is different from that for taking away existing features. If a feature doesn't yet exist, a successful proposal will show how it provides additional and non-trivial utility. If a feature already exists, a successful proposal to remove it will show how

Re: [swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

2016-06-06 Thread Xiaodi Wu via swift-evolution
Wouldn't this be covered under SE-0092? On Mon, Jun 6, 2016 at 15:59 Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote: > Given a protocol with an associated type: > > protocol Foo > { > associatedtype Bar > } > > it should be possible to define a protocol conforming to Foo,

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин wrote: > I've prepared a proper draft: > > > https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md > > When you propose this: Syntax in protocol extensions protocol

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 6:46 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > When I suggested this syntax in the acceptance thread for SE-0099, Chris > said it should be written up as a proposal. I'm sure this will get lost in > the WWDC shuffle, but here goes. >

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
>> >>> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz <tseit...@icloud.com> >>> wrote: >>> >>>> >>>> >>>> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution < >>>> swift-evolution@swi

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 7:10 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 10, 2016, at 12:59 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jun 10, 2016 at 12:30 PM, let var go <letva...@gmail.com>

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
...@gmail.com>: >> >> >> >> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> >> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution < >> swift-evolution@

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
What's the behavior currently with `if case let (foo?, bar?, baz?)...`? On Sun, Jun 12, 2016 at 19:53 plx via swift-evolution < swift-evolution@swift.org> wrote: > This proposal should specify if the tuple is evaluated “eagerly” or as an > “early-exit”. > > That is, if we write `if let

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > > And to follow-up to myself once again, I went to my "Cool 3rd Party > Swift Repos" folder and did the same search. Among the 15 repos in that > folder, a joint search returned about 650 hits

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
not sufficient grounds for keeping something confusing, IMO. > > > It’s more readable. It does that better. > Earlier in this thread and others, I gave my reasoning where I disagree with this assertion about being more readable. > The tests also seem to show that (bizarrely) it’s

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 7:45 AM, Dany St-Amant wrote: > > > Le 10 juin 2016 à 02:25, Xiaodi Wu a écrit : > > > > * The word "where" does not consistently imply `break` or `continue`. In > current Swift, `where` implies `break` in the context of a `while`

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
t long. It's more like, "Does this work > like X, or does this work like Y? Let's see...oh, it works like X. Ok." > That's the entire learning curve...about 5 seconds of curiosity followed by > the blissful feeling of resolution. > > On Fri, Jun 10, 2016 at 9:32 AM X

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
g to ask a single question. As long as its >>> not a dangerous tool (and it isn't), then keep it in the workshop for those >>> times when it comes in handy. And even if there is some initial confusion, >>> it doesn't sound like it lasted that long. It's more like, &qu

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 12:47 PM, James Berry <jbe...@rogueorbit.com> wrote: > > On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I think this idea--if you don't like it, then you don't have to use it--is > indica

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 12:51 PM, Brent Royal-Gordon wrote: > > The thought here is along the lines of what Chris said, quoted above, > and repeated here: "The extended C family of language [...] is an extremely > popular and widely used set[;] programmers move around

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 1:45 PM, L. Mihalkovic wrote: > I humbly suggest that some people who are afraid of seing it go might want > to lookup LINQ (c#) to get a sense of could be done in the future if/when > the idea of a WHERE clause gets revisited. With the

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
it. It seems >>> strange to get rid of a tool because not everyone understands how to use it >>> immediately, without ever having to ask a single question. As long as its >>> not a dangerous tool (and it isn't), then keep it in the workshop for those >>> times wh

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
ndy. And even if there is >> some initial confusion, it doesn't sound like it lasted that long. >> It's >> more like, "Does this work like X, or does this work like Y? Let's >> see...oh, it works like X. Ok." That's the entire learning >> curve...about 5 s

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 1:14 PM, Ryan Lovelett wrote: > @Xiaodi Wu a couple of times you've said things were "explicit" this or > that. > > > * Swift is explicitly a C-family language. In most or all other > C-family languages, for loop statements allow specification

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
d to be a defined line to come to a conclusion. It's not even on the same playing field. I do not want a swift compiler flag that takes my idea and gets a team of > contractors to build it... to take it to a ridiculous extreme :). > > Sent from my iPhone > > On 10 Jun 2016, at 19:10

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 2:10 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > Unlike in switch statements and do loops, a for-in loop's where-clause > is separated from the pattern it modifies. > > (I think "do loops" is supposed to be "do-catch statements"?) > >

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
thing that’s clearly much better than what we have now. > > Karl > > On 10 Jun 2016, at 17:24, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: &

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 2:08 PM, Erica Sadun wrote: > > > On Jun 10, 2016, at 1:06 PM, Rob Norback via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Following Brent's logic that the for-in where should mimic the switch > statement functionality, then this

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 3:04 PM, Christopher Kornher <ckorn...@me.com> wrote: > > On Jun 10, 2016, at 1:52 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jun 10, 2016 at 2:38 PM, Brandon Knope via swift-evolution < >

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 3:17 PM, Haravikk wrote: > > 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 >

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 2:42 PM, Christopher Kornher wrote: > -1 > > An alternative would be to: > > 1) State clearly in all relevant documentation that ‘where’ filters and > ‘while’ terminates. > 2) Eliminate the use of ‘where’ within ‘while’ clauses. > > This seems pretty

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 2:35 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > On 10 Jun 2016, at 19:10, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > So "inessential" alone is not a good sole criterion--I agree. But it is &g

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 2:38 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > Thanks for the laugh! > > The last week or so is actually stressing me out about the direction where > swift is going… > > I hope it is just a fleeting feeling but that remains to be seen. I

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 3:15 PM, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > -1 > > Am 10.06.2016 um 21:10 schrieb Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org>: > > if case .some(let Point.cartesian(x, y)) where x < y = >

Re: [swift-evolution] Add max/min to floating point types

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 1:24 PM, Darren Mo via swift-evolution < swift-evolution@swift.org> wrote: > Today, one can get max/min by doing: > > let max = Float.greatestFiniteMagnitude > let min = -Float.greatestFiniteMagnitude > On review of the proposal for the new FloatingPoint, I too commented

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
e unwanted books by continuing, or breaking, or a fatal error. I know, it's unpleasant, but you are rejecting them by act or by omission; and of those only the act shows intentionality. On Fri, Jun 10, 2016 at 19:29 Dany St-Amant <dsa@icloud.com> wrote: > > Le 10 juin 2016 à 13:5

Re: [swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 9:55 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I really love this idea. My mental model of it is that it is exactly like > ‘defer’, except it works on the lifetime of the object instance instead of > a function/method. Same thing,

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 9:25 PM, Jonathan Hull wrote: > Please leave this feature in! > > One of the places I get bitten the most during refactoring is somehow > missing a ‘continue’ statement inside the loop (and I hear that is a common > issue). For-in-where lets me guard

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

2016-06-09 Thread Xiaodi Wu via swift-evolution
There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing. In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use

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

2016-06-09 Thread Xiaodi Wu via swift-evolution
On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa@icloud.com> wrote: > > Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > There have been, in previous threads, several examples given where users > of Swift hav

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bkn...@me.com> wrote: > > > On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa@icloud.com> wrote: > >

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

2016-05-25 Thread Xiaodi Wu via swift-evolution
On Wed, May 25, 2016 at 12:49 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On May 25, 2016, at 12:41 PM, Charlie Monroe > wrote: > > Got it. You could also say it is safer because you can't have a supertype >

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

2016-05-27 Thread Xiaodi Wu via swift-evolution
I don't believe that was the case with the semicolons in the original for;; loop, was it? On Fri, May 27, 2016 at 20:37 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On May 27, 2016, at 7:22 PM, Erica Sadun wrote: > > >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

2016-05-27 Thread Xiaodi Wu via swift-evolution
This looks good. I like your use of the term "lossless"; perhaps we can use it consistently, i.e. LosslessStringConvertible. The implication by comparison would be that CustomStringConvertible makes no guarantee of losslessness. On Fri, May 27, 2016 at 23:52 Austin Zheng via swift-evolution <

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

2016-05-27 Thread Xiaodi Wu via swift-evolution
I'd hope not. You can't guarantee String -> Double -> String roundtripping, but Double -> String -> Double should be lossless. On Sat, May 28, 2016 at 00:11 Jacob Bandes-Storch wrote: > Does "lossless" preclude floating-point numbers from being printed in > decimal unless

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

2016-05-27 Thread Xiaodi Wu via swift-evolution
I don't recall whether it was in this thread or another that this point was made by the core team, but if I'm remembering correctly: it was shared that the protocol is now called CustomStringConvertible because conforming types provide a *custom* description, not merely an ordinary description.

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

2016-06-10 Thread Xiaodi Wu via swift-evolution
On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <swift-evolut...@haravikk.me> wrote: > > On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > * Swift is explicitly a C-family language. In most or all other C-family > languages

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
On Sat, Jun 11, 2016 at 2:42 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > Am 10.06.2016 um 07:08 schrieb Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>: > > On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa@icloud.com> wrote: >

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
swift.org> wrote: > > > > Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>: > > On Fri, Jun 10, 2016 at 6:10 AM, Karl <razie...@gmail.com> wrote: > >> -1 >> >> * Swift is explicitly a C-f

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
On Sat, Jun 11, 2016 at 2:53 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>: > > On Fri, Jun 10, 2016 at 6:10 AM, Karl <razie...@gmail.com> wrote: > >&

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution < > swift-evolution@swift.org>: > > > On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution < > swift-evol

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution < >> swift-evolution@swift.org>: >> >> >> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Fri, Jun 10, 2016 at 7:18 AM

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu <xiaodi...@gmail.com>: >> >> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz <tseit...@icloud.com> >> wrote: >> >>> >>> >>> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution < &

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

2016-06-11 Thread Xiaodi Wu via swift-evolution
>> >> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic < >> laurent.mihalko...@gmail.com>: >> >> >> >> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> >> Am 10.06.

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
Actually, at least where I'm from, it wouldn't be a comma, it'd be a bar: ∀ x ∈ X | x > 0. Moreover, as has been pointed out, the use of 'where' in math is also not universally loved. On Mon, Jun 13, 2016 at 11:03 Charlie Monroe wrote: > `while`, `until` and `unless`

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
t;> sitting right there, because you don't want someone else to have to learn >>> something. >>> >>> On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>>> I think this discussion has made it pretty plain that what is claimed >>>

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
gt;> >>>>> So by getting rid of the "where" clause, I believe that you are >>>>> actually encouraging bad programming practice. Instead of encouraging the >>>>> new user to learn this very simple construct that will ultimately make >>>

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
>>>> just "do what they know". I think that is terrible, and you are doing them >>>> a disservice. >>>> >>>> And from a personal standpoint, you are telling me that I have to write >>>> smelly code, even though there is this pe

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
text you write in a `where` clause. > >> l8r >> Sean >> >> >> > On Jun 13, 2016, at 9:19 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> > >> > How do you mean? I don't follow. >> > On Mon, Jun 13, 2016 at 09:11 Sean Heber <s...@fifth

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
, 2016 at 1:54 AM Jose Cheyo Jimenez <ch...@masters3d.com> >> wrote: >> >>> --1 >>> >>> I think it would be a waste of the community's time to do a formal >>> review when only two people are in favor of this removal. >>> >>> 'f

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
This is not a sound argument. If your filtering can be expressed as a where clause, then you would only have to read one line into the loop to see it in the form of a guard clause. Moreover, if what you're arguing is that you shouldn't ever have to *read* inside the loop to know if a sequence is

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
On Mon, Jun 13, 2016 at 12:24 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > > On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I think this discussion has made it pretty plain that what is claimed to

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
rol-flow logic is on one single >>>>>> line, and once it is known that "where" operates as a filter operation, >>>>>> it >>>>>> all works together in a single, harmonious statement that declares >>>>>> exactly >

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

2016-06-14 Thread Xiaodi Wu via swift-evolution
The performance of stdlib methods is not fixed in stone. And a language feature being undocumented wouldn't explain why the entire stdlib uses it only three times :) On Tue, Jun 14, 2016 at 1:42 AM Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > I used to do low latency

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
How do you mean? I don't follow. On Mon, Jun 13, 2016 at 09:11 Sean Heber <s...@fifthace.com> wrote: > > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe <

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
{..} > or > for item in collection breakif item > 100 {..} > or > for item in collection limit item > 100 {..} > or > for item in collection stop item > 100 {..} > or other keyword. > > > On 13.06.2016 16:36, Xiaodi Wu via swift-evolution wrote: > >> On Mon, Jun 13,

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
y independent of `for...in` loops and was well precedented in C languages. > > Brandon > > Sent from my iPad > > On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > This is not a sound argument. If your filtering can be expres

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
2016, at 9:19 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > > How do you mean? I don't follow. > > On Mon, Jun 13, 2016 at 09:11 Sean Heber <s...@fifthace.com> wrote: > > > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution < > swift-evoluti

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe wrote: > if-continue. But I gladly took upon for-in-where as soon as I found out > about it since it's more expressive and simply is less typing. > I don't think we use the term 'expressive' in the same way. I understand

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

2016-06-13 Thread Xiaodi Wu via swift-evolution
`++` or `for;;` loops? I'd say our case is at least as strong as > that for `for;;` loops. By comparison, if I recall, the `for;;` loop was > argued to be ill-fitting the rest of the language and lacking in usage, but > it certainly had utility independent of `for...in` loops and was well > p

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

2016-06-14 Thread Xiaodi Wu via swift-evolution
And from the WWDC Platforms SOTU: "Swift is super simple and approachable It's great as a first language. And in fact, we think this is so important that when we designed Swift this was an explicit design goal." I would be absolutely against adding any more sugar to the for loop. In that

  1   2   3   4   5   6   7   8   9   10   >