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

Regards (From mobile) > On Jun 14, 2016, at 7:01 AM, Charlie Monroe wrote: > > >> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon >> wrote: >> See the benchmarks me and Erica have posted here a few days back - even with the lazy accessor, if you decided to use filter(_:), you lo

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

Regards (From mobile) > On Jun 14, 2016, at 8:41 AM, Charlie Monroe wrote: > >> I used to do low latency java for trading systems... the kind of coding >> where we would go out of our way to avoid ANY intraday gc activity (yes it >> can be done, even for parsing xml files). So we cared about

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 coding practices, it has after

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

> On Jun 14, 2016, at 1:22 AM, Haravikk via swift-evolution > wrote: > > >> 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 whethe

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

Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, because it has knock on effects of making other things more complicated. But I do see how for the most simple case of unwrapping a single Optional, it makes sense. As much as I would like Brent’s proposal to make thing

[swift-evolution] [Discussion] Default Closure Arguments

I'd like to be able to do this: func callSomething(callback: (test: (arg: Int = 4) -> Void) -> Void) { callback(test: { print($0) }) } callSomething { test in test() } Ideally the default argument would be part of the closure's type signature. If-not then it could be part of callSome

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

On 13.06.2016 18:59, L. Mihalkovic via swift-evolution wrote: I don’t dispute that we *could* live without “where” - that is not the point. We could also live without classes or generics or any of a variety of other features - but why should we when we don’t have to? The corollary question every

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

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution >> wrote: >> >> I am 100% with Charlie on this. Expressiveness has to do with the >> *effectiveness* of conveying a thought or a feeling. >> >> Keep

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

> On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution > wrote: > > Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, > because it has knock on effects of making other things more complicated. But > I do see how for the most simple case of unwrapping a si

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

> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution > wrote: > For those particular keywords, I’d prefer having them (or equivalents). I’m > not sure if I’d prefer having *all* of them—`where/unless` and > `while/until`—or just one from each “pair”…I could go either way. In the proposal, m

Re: [swift-evolution] [Discussion] Default Closure Arguments

What would this help you express? It is fairly difficult to read the type and understand your motivation from this reduced example. It is clear what you want but not what it wins you or us. On Tue, Jun 14, 2016 at 3:40 AM, Andrew Bennett via swift-evolution < swift-evolution@swift.org> wrote: > I

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

The equivalent in Swift would be .filter(), and you're free to use it if you prefer to express yourself that way. Notice how these are almost never paired with loops. It's like mixing chocolate and steak. On Tue, Jun 14, 2016 at 8:50 AM plx via swift-evolution < swift-evolution@swift.org> wrote:

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

FWIW I don't think we need all "4", just like we don't need `unless` as a pair to current `if` or `until` as a pair for current `while` loop. I.e. we have "continue" with current `where`, and you can use boolean inversion `!`. As for "break"(while) - my opinion the for-in loop will be more pow

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

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 sense

[swift-evolution] Property with class and protocol type

Hi all, In Obj-C we have: @property UIViewController *viewController; Is there any reason we don't have in Swift: var viewController: UViewController Do you think it will be nice feature to have in Swift? One example I have is is to have VC's container with view controllers(some forms) which i

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

I’m a bit late to this conversation, and I don’t totally understand the goal. There are a *lot* of things you can do in for…in loop with pattern matching that also would supposedly go against this interpretation of approachability. Pattern matching in general might be considered to go against th

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

On Tue, Jun 14, 2016 at 12:16 PM, David Waite wrote: > I’m a bit late to this conversation, and I don’t totally understand the > goal. > > There are a *lot* of things you can do in for…in loop with pattern > matching that also would supposedly go against this interpretation of > approachability.

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

On Tue, Jun 14, 2016 at 12:37 PM, Xiaodi Wu wrote: > On Tue, Jun 14, 2016 at 12:16 PM, David Waite < > da...@alkaline-solutions.com> wrote: > >> I’m a bit late to this conversation, and I don’t totally understand the >> goal. >> >> There are a *lot* of things you can do in for…in loop with patter

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

On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote: > On Tue, Jun 14, 2016 at 12:16 PM, David Waite solutions.com> wrote: >> I’m a bit late to this conversation, and I don’t totally understand >> the goal. >> >> There are a *lot* of things you can do in for…in loop with pattern

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

We're going in circles again. I addressed this with relation to `guard`, and I would reply in the same way about `for case`: The fact is that there are even experienced users of Swift who see `where` and affirmatively believe it does what it does not do. The same cannot be said for `for case`. Tha

Re: [swift-evolution] Property with class and protocol type

=D We’re already discussing this in a lot (I mean really lot) different threads. Search for existentials or Any<…> or type<…> or All<…>. SE–0095 is the first step in that direction. We want a shorthand version first and design a more complex functionality like Any<…> later. Any (I prefer

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

Regards (From mobile) > On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution > wrote: > > I’m a bit late to this conversation, and I don’t totally understand the goal. > > There are a *lot* of things you can do in for…in loop with pattern matching > that also would supposedly go aga

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 12, 2016, at 9:08 PM, Charlie Monroe wrote: >> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Unavailable doesn't mean un-callable. >> If you're marking an override or required initialiser as unavailable, it's >> still

Re: [swift-evolution] Access modifier blocks

I dont agree. I think extensions serve this purpose very well. Here is what I do: I start with the type declaration only containing properties (public or private). I then create one extension per access level required and one per protocol conformance and per superclass overrides. We get: class

Re: [swift-evolution] Access modifier blocks

And if you want to be able to declare properties in extensions, which I'm not a fan of, I think it would still be more a appropriate proposal than one that adds another way to group access modifiers. > On 14 Jun 2016, at 13:18, David Hart via swift-evolution > wrote: > > I dont agree. I think

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

Why are you unhappy about this design goal? Simple != simplistic, and powerful != complicated. Approachability has to do with the slope of the learning curve, not how high the curve goes. On Tue, Jun 14, 2016 at 14:18 L. Mihalkovic wrote: > > > Regards > (From mobile) > > On Jun 14, 2016, at 7:

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

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution > wrote: > >> >> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon > > wrote: >> >>> Upon accepting SE-0099, the core team is removing `where` clauses from >>> condition clauses, writing "the 'where' k

Re: [swift-evolution] Access modifier blocks

Your style may vary, but in my experience the access level of two functions has very little effect on how they should be grouped. Let's take an example: a class with two init functions. (If you want a concrete example: a subclass of UIView has init(frame) and init(coder)). While the inits take dif

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

> What about just this? > for i % 2 == 0 in sequence { ... } > > The first new identifier gets to be the index variable and subsequent new > identifiers are errors. If that weren't a syntax error, I would expect it to loop over `[true, false, true, false, …]`. -- Brent Royal-Gordon Architechi

Re: [swift-evolution] Property with class and protocol type

Not true, we already stated a clear rule how existentials should work with class-requirements long time ago (don’t mind lowercased any here): Nested any<...> A nested any<...> may declare a class or any-class constraint, even if its parent any<...> contains a class or any-class constraint, or a

Re: [swift-evolution] Property with class and protocol type

One more thing for clarity: Any-class requirement: This must be the first requirement, if present. This requirement consists of the keyword class, and requires the existential to be of any class type. Class requirement: This must be the first requirement, if present. This requirement consists

Re: [swift-evolution] Access modifier blocks

Your approach has a major flaw: methods from extensions can't be overridden (at least for now). As long as you want to your controller to be subclassed and allow overriding your public/internal methods, you need to move them from extensions to the main class scope. Which simply sucks and may be

Re: [swift-evolution] Nil coalescing operator precedence

On Sun, Jun 12 2016 at 02:01:17 AM, Andrey Fidrya via swift-evolution wrote: > Nil coalescing operator has very low precedence and it's very easy to forget > the parentheses. > It's tempting to write something like this: > > let result = v1 ?? 0 + v2 ?? 0 > > Which will resolve to > > let result

Re: [swift-evolution] Nil coalescing operator precedence

I've given it some more thought... Even expressions with single ?? can be confusing. For example: 1) let z = a ?? x + y + z Actually it's let z = a ?? (x + y + z) But can be mistakenly interpreted as let z = (a ?? x) + y + z 2) Same problem with ?: let z = a ? b : c + x + y It's let z = a ?

Re: [swift-evolution] Nil coalescing operator precedence

This is an orthogonal issue to the first that you identified. The first has to do with the associativity of the operator, the second has to do with the precedence of the operator. I think there's sufficient confusion about the first that it's worth addressing. However, with respect to precedence,

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

As you will see from earlier messages, the confused user is both quite real and *is* on this list. Nor, mind you, are pedagogical concerns to be trivialized; they are serious concerns for the design of the language. On what grounds do you assert that something is "not confusing at all" when there h

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

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 based on understanding. In my opinion keywords have a tendency to create more

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

This is a great point, Jo. I'd love to see a conversation about this, actually, and starting a new thread would probably be the best way to get the widest attention :) On Tue, Jun 14, 2016 at 21:43 Jo Albright wrote: > This is probably going to get lost in this massive chain. But I am going > to

[swift-evolution] Arbitrary-sized integers

I'm writing a program that would need Int128s. Since Swift uses LLVM and LLVM has good support for arbitrary-sized integers (well, up to 2^24 bits anyways), I was wondering if there was any interest in having arbitrary-sized integers in Swift. Félix

Re: [swift-evolution] Property with class and protocol type

I new this was going to happen... of course with enough code around you can prevent anything. But that was precisely my point: with that proposal, these rules are the only way to make sure that something as clearly wrong as my simple example cannot happen. And this is to me the worst possible wa

Re: [swift-evolution] Property with class and protocol type

You need 3 long paragraph to explain it, the alternative I offer requires none. https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 Regards (From mobile) > On Jun 14, 2016, at 11:44 PM, Adrian Zubarev via swift-evolution > wrote: > > One more thing for clarity: > > Any-class

Re: [swift-evolution] Arbitrary-sized integers

128-bit Ints have been discussed here a few weeks ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018957.html > On Jun 15, 2016, at 5:50 AM, Félix Cloutier via swift-evolution > wrote: > > I'm writing a program that would need Int128s. Since Swift uses LLVM and LLVM

Re: [swift-evolution] Property with class and protocol type

Self correction inline... > On Jun 15, 2016, at 6:27 AM, L. Mihalkovic > wrote: > > You need 3 long paragraph to explain it, the alternative I offer requires > none. > > https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 > > Regards > (From mobile) > >> On Jun 14, 2016, at

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

> On Jun 15, 2016, at 3:57 AM, Jon Akhtar via swift-evolution > wrote: > > How about the goal of it being a delightful language to program in. Historyprooves that goals are rarely enterely wrong... It is how they are carried out that more often is questionable. > I think that is getting lo

Re: [swift-evolution] Property with class and protocol type

I guess you don’t understand that a so called proposal should have enough details to explain the proposed behavior to someone who is not the author of the proposal. You’re offering is fine but a few unexplained lines of your gist wouldn’t make through a proposal review at all. I rather give a bo

Re: [swift-evolution] Arbitrary-sized integers

There is also a fairly robust implementation of arbitrary size integers here https://github.com/lorentey/BigInt/tree/master/Sources On Tue, Jun 14, 2016 at 10:02 PM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > 128-bit Ints have been discussed here a few weeks ago: > >