Re: [swift-evolution] [Review] SE-0179: Swift `run` Command

> On 17 May 2017, at 20:32, Richard Wei via swift-evolution > wrote: > > Excellent, except that `--chdir` and `--in-dir` are confusing. Why not use a > long, clear name, just like `—enable-prefetching`? Consider `—working-dir` & > `—preexec-working-dir` That would

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

Hi Tony, > On 6 May 2017, at 04:12, Tony Allevato via swift-evolution > wrote: > > These warnings are emitted for any reference to a deprecated entity, > including those in the same file. In some cases, however, it may be necessary > and correct to continue

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution > wrote: > > Why? Not trying to be smart, but the reasoning is in Robert’s proposal: >> Their inclusion in the language complicates every part of the compiler >> stack, uses a syntax that can be

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

Hi Erica, > On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution > wrote: > > Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible > to end-users. Most Swift users will never know anything changed from > S3/SE-0169 but it would support

Re: [swift-evolution] [Proposal] Nested extensions

Hi Tino, > On 14 Apr 2017, at 19:40, Tino Heth via swift-evolution > wrote: > > This concept tries to avoid all objections that were raised against the > various modells (of course, it triggers fresh ones at the same time ;-), and > because it is purely additive,

Re: [swift-evolution] Enhancing access levels without breaking changes

Hi Tino, > On 8 Apr 2017, at 22:03, Tino Heth via swift-evolution > wrote: > > I wish this would only be a joke, but writing the example, I actually started > liking the concept (but I have a terrible headache right now which might > affect my mind) — so either

Re: [swift-evolution] Type-based ‘private’ access within a file

Hi Brent, > On 6 Apr 2017, at 09:10, Brent Royal-Gordon wrote: > > So I'm not sure why you're invoking Objective-C to argue that we need a > type-based private. I’m not trying to invoke the ghost of Apple-languages past, seriously :) I was outlining a use-case of

Re: [swift-evolution] Type-based ‘private’ access within a file

> On 6 Apr 2017, at 02:54, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > The developer adds a free function to the file. Or an extension of another > type. Or another type entirely. And they put it in the same file because it > needs to work with the

Re: [swift-evolution] Type-based ‘private’ access within a file

> On 4 Apr 2017, at 10:01, David Waite via swift-evolution > wrote: > > I believe we can leave the option open of widening private later as part of a > tasked redesign of access control after Swift 4.0. I’d prefer to not widen > private before we have evaluated

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

Hi Doug (and list), > What is your evaluation of the proposal? -1 > Is the problem being addressed significant enough to warrant a change to > Swift? No, I also think it is not the _correct_ answer to the actual issues with access control in Swift right now. > Does this proposal fit well

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution > wrote: > > We need more examples to make this case. How do we provide those examples? This thread has been actively discussed for close to a week now, so it would be good to do something concrete

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

Sent from my iPhone > On Jul 20, 2016, at 12:47 PM, Dave Abrahams wrote: > > > on Wed Jul 20 2016, Arnold Schwaighofer wrote: > >>> On Jul 20, 2016, at 9:54 AM, Andrew Trick wrote: >>> >>> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer

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

Sent from my iPhone > On Jul 20, 2016, at 6:50 AM, Dave Abrahams wrote: > > >> on Tue Jul 19 2016, Dmitri Gribenko wrote: >> >>> On Tue, Jul 19, 2016 at 10:51 PM, Chris Lattner wrote: >>> The review of "SE-0125: Remove NonObjectiveCBase and >>>

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

On Darwin and iOS systems it would be hard to implement a uniques check efficiently for objective c objects. You can't rely on retainCount is what I remember. NonPointer ISA, slide tables that contain weak and actual reference counts would make it hard to make such a check efficient. This

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 9:41 PM, Arnold wrote: > > > > Sent from my iPhone > >> On Jul 16, 2016, at 9:23 PM, Andrew Trick wrote: >> >> >>> On Jul 16, 2016, at 9:17 PM, Arnold wrote: >>> >>> >>> >>>

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 9:23 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 9:17 PM, Arnold wrote: >> >> >> >> On Jul 16, 2016, at 8:45 PM, Andrew Trick wrote: >> >>> On Jul 16, 2016, at 8:36 PM,

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 8:45 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 8:36 PM, Arnold wrote: >> >> Thank you for the feedback. Answers online. >> >> Sent from my iPhone >> >>> On Jul 16, 2016, at 7:38 PM, Andrew Trick

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Thank you for the feedback. Answers online. Sent from my iPhone > On Jul 16, 2016, at 7:38 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution >> wrote: >> >> Replace isUniquelyReferenced by >>

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

`isUniqueReferencedNonObjC` is useful if our storage could be other a native Swift class or an objective-c class instance. An example of this is Array's storage: It could either be a native Swift class instance or if the array was bridged from cocoa an NSArray instance. Before we write to the

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

Just to clarify: I was +1-ing real world `where` clauses. I am against this proposal. So… -1 from me on this proposal (and SE-0099 for what it’s worth). Sorry! -t (Thanks for pointing out the confusion my email may have caused, Goffredo) > On 28 Jun 2016, at 10:39, Tony Arnold

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

I wasn’t going to be +1 guy, but “+1”: I use where pretty heavily across both `if let` and in `for … in` loops. I find both really readable when formatted, and I’d be disappointed to see them go. I’m super annoyed that I missed (see “wasn’t paying attention during”) the review of SE-0099

Re: [swift-evolution] Asserts should not cause undefined behaviour

'assert' evaluates the condition and aborts only in Odebug builds. 'precondition' evaluates the condition and aborts also in optimized -0 builds. As far as I remember the decision was made to give it this semantics to mimic C's assert() function. If an abort is desired in optimized builds one

Re: [swift-evolution] Asserts should not cause undefined behaviour

Sent from my iPhone > On Jan 2, 2016, at 6:35 PM, Dave Abrahams wrote: > > >> On Jan 2, 2016, at 2:57 AM, Arnold wrote: >> >> 'assert' evaluates the condition and aborts only in Odebug builds. >> >> 'precondition' evaluates the condition and