Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

The C99 spec changed the scoping rules to address the very issue you are asking about having any "real-world impact". Yes, the variable outside does matter. It's why you see some code like this, even with C++ because it used to not scope locally there too with all compilers: {for (int i= 0;

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

> On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution > wrote: > > While this style works, and definitely can substitute for a classical for > loop, it is not quite as nice, because it cannot limit i’s scope to the loop. > The variable will be visible

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body. Charles > On Apr 2, 2016, at 8:43 PM, Andrew Bennett via swift-evolution >

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

On that note here is a convenient pattern I've used in the rare cases I haven't been able to convert to a "for in" syntax when refactoring: var i = 0 while i < 10 { defer { i += 1 } print(i) } To be honest I don't really mind this syntax, I often found during refactoring: * the

Re: [swift-evolution] Feature proposal: Range operator with step

General numerics comments: We’ll want internal state and computation to be Double for Float or Double, and Float80 for Float80. This confers a couple significant advantages: - There are useful loops with more than 2**31 steps, which means having _step be Int is insufficient on 32-bit systems.

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

Because you're coming to the discussion late, the arguments you're making are a little out of date. It's no longer a case of not removing these features. It's now a case of having a compelling reason to put them back. I trust you've read the proposals that were put forward. For the benefit of

[swift-evolution] Revisiting 0004 etc. - Swift deprecations

Warning - long post. I know that some folks really hate long posts, so let me apologize right now for this being a long post. Please feel free to skip right on past it. I posted it on a weekend, when there¹s less mailing list traffic, but that doesn¹t make it any shorter. Warning - revisits two

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> As as been pointed out in the past, why not make a leading dot mean static > (including enum). This would be nice and consistent. And it would break the common pattern of doing things like: string.compare(otherString, options: [.caseInsensitive, .numeric]) Leading dot can only mean

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

As as been pointed out in the past, why not make a leading dot mean static (including enum). This would be nice and consistent. On Sunday, 3 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > Matthew Johnson via swift-evolution >

Re: [swift-evolution] Feature proposal: Range operator with step

Another alternative would be to sub-divide the generator into segments of Int.max elements. This means that error may still potentially creep in if there are enough of these steps, but it would be considerably less error-prone than the accumulation method, without the same performance penalty

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

> What is your evaluation of the proposal? I am strongly opposed to the changes to the names of functions implementing set operations, as it is going to introduce a lot of confusion. While I'm a fairly rigid about consistency, I do think that there are acceptable exceptions to any set of

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> What is your evaluation of the proposal? I think there is a lot of value to allowing trailing closures in the guard condition clause. However, not at the cost of inconsistency. We have reviewed many proposals over the last month that addressed consistency issues in the Swift language, and if

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 01.04.2016 um 00:23 schrieb Xiaodi Wu via swift-evolution > : > > All true. I call that Erica's solution because her proposal is where I first > found it sketched out. > > I'm not convinced that Erica's solution is definitely the right answer > because: > >

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Matthew Johnson via swift-evolution wrote: > >> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution >> wrote: >> >> Douglas Gregor via swift-evolution >> wrote: >>> Hello Swift community, >>> >>> The

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

The correctness of this proposal seems somewhat self-evident. +1. Charles > On Mar 31, 2016, at 10:41 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance > Member

Re: [swift-evolution] [META] Re: Mailman?

Hi Keith, can you give some more details on how to do this? I'd love to use Unison for this, but I have no idea how to set this up. Any help is greatly appreciated. -- Ilya On Wed, Mar 9, 2016 at 1:47 PM Keith Smiley via swift-evolution < swift-evolution@swift.org> wrote: > For those who are

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

+1 On Thu, Mar 31, 2016 at 11:41 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance > Member Implementations" begins now and runs throughApril 5, 2016. The > proposal is

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Hello Matthew, If the goal is to make rules for accessing static members and enum cases more consistent, why can’t static members be accessed from inside the type cope with a dot prefix (sorry for the grim example)? struct Person { static let lifeExpectency: Int = 80 let age: Int

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 1, 2016, at 7:37 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Kind of. If I may steelman* optional members for a moment… I’d actually go a

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Sent from my iPad > On Apr 2, 2016, at 7:04 AM, Lukas Stabe via swift-evolution > wrote: > > All use-cases I had for optional methods in protocols in Objective-C are > covered nicely by providing a default implementation in a protocol extension, > so I don't

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

All use-cases I had for optional methods in protocols in Objective-C are covered nicely by providing a default implementation in a protocol extension, so I don't think optional protocol methods should be a thing in pure Swift. > I do not understand why an optional method should require a

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Very good points Dietmar, but there is one more bit about default implementations in extensions that makes it worse to use than the old Objective-C model... the complex dispatch rules that can make the executed method type dependent and not instance dependent. We really need dynamic dispatch