Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

If I might be so bold, perhaps we should consider the opposite. Suppose you have a conditional statement inside a loop. It would be easier for the reader to understand what it does if “break” meant the same thing regardless of whether you used “if” or “switch” for the condition. Right now, these

Re: [swift-evolution] stored properties in extensions (was: associated objects)

That's great! I suppose the idea of allocating a bit of extra storage for similar data in value types is some sort of heresy? Would there be a conceptual reason for that; which explains why it's okay for reference-types but not for values? Personally I feel like it's a kind of C legacy, due to

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

> On Oct 13, 2016, at 4:26 AM, Alex Blewitt via swift-evolution > wrote: > > On 13 Oct 2016, at 11:06, Haravikk via swift-evolution > > wrote: >> >>> >>> On 11 Oct 2016, at 19:43, Erica Sadun via

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

> On 13 Oct 2016, at 16:19, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > If I might be so bold, perhaps we should consider the opposite. Suppose you > have a conditional statement inside a loop. It would be easier for the reader > to understand what it

Re: [swift-evolution] [Pitch] deprecating ManagedBufferPointer

I created a proposal: https://github.com/apple/swift-evolution/pull/545 > On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Oct 11 2016, Károly Lőrentey

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

> On Oct 13, 2016, at 9:31 AM, Chris Lattner via swift-evolution > wrote: > >> >> On Oct 13, 2016, at 4:26 AM, Alex Blewitt via swift-evolution >> > wrote: >> >> On 13 Oct 2016, at 11:06, Haravikk via

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

Hello Chris, Thank you for updating me, read this and other related info again thoroughly and will act accordingly. In the mean time I will work dynamically on dynamics :o) Currently I suspend my topic. and bring this back again much later but then tagged with [out of scope] If this is

Re: [swift-evolution] private & fileprivate

On Sat, Oct 8, 2016, at 07:42 AM, Anton Zhilin via swift-evolution wrote: > As far as I can see, almost all people, who talk here, agree that > private / fileprivate distinction brought more harm than good. Despite > corresponding proposal being accepted. > I think, it means that current

Re: [swift-evolution] private & fileprivate

Please do NOT drop the current distinction between *private* and *fileprivate* as it is now in Swift 3 It is needed for correct OOP. As written before, but now a bit more compact, I hope: I would like to have the inner members of a class as default private, (not fileprivate) that is, that

Re: [swift-evolution] private & fileprivate

Sorry, that was a little harsh. I just think there are a lot of opinions here based on personal biases and not necessary the best prior experiences. If you want good OOP it is best to let people with *real* OOP experience, like SmallTalk, work it out.

[swift-evolution] [Discussion] API Guidelines

Hi there, I am really grateful for the API guidelines that were created as part of Swift 3, however, I'm having trouble with distinguishing which part of the method name should be already an argument. To illustrate this, here are two examples: // On Array public mutating func append(contentsOf

Re: [swift-evolution] private & fileprivate

Daniel, I would be interested to hear what, exactly, are the benefits your project has realized from the new “private” compared to the old “private” (which is now called “fileprivate”). Were there problems caused by the old “private” that have been solved by the new “private”? Major problems?

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

> On Oct 13, 2016, at 12:03 PM, Ted F.A. van Gaalen > wrote: > > Hello Chris, > > Thank you for updating me, > read this and other related info again thoroughly > and will act accordingly. > In the mean time I will work dynamically on dynamics :o) > Currently I suspend

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Karl, interesting point... perhaps a similar scheme could work for value types (using the COW refcount)? On Thu, 13 Oct 2016 at 16:02 Karl Wagner wrote: > That's great! I suppose the idea of allocating a bit of extra storage for > similar data in value types is some sort of

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I was thinking for reference types we would probably want to use the extra space in the refcount field (as discussed earlier in the thread). For value types, we might want to have a single data structure (probably COW) holding all associated values for the value types on the stack frame. That

Re: [swift-evolution] private & fileprivate

I question the practicality of "use private heavily simply because I don’t want the burden of mixing private and fileprivate". In our experience in converting a very mature Swift application, we had no choice but to use both because we wanted private as much as possible but that's too

Re: [swift-evolution] private & fileprivate

fileprivate is not essential but I also would like to defend keeping it, at least for now. I find it useful in practice. In some cases, I can’t put a declaration in the global file scope (where fileprivate and private are essentially the same thing). For example, for organizational reasons I

Re: [swift-evolution] [Proposal] Enums with stored properties

> On 12 Oct 2016, at 21:21, Charles Srstka via swift-evolution > wrote: > >> On Oct 11, 2016, at 8:51 PM, Xiaodi Wu wrote: >> >> On Tue, Oct 11, 2016 at 8:21 PM, Charles Srstka via swift-evolution >> wrote: >>> On

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

on Wed Oct 12 2016, Nate Cook wrote: >> On Oct 12, 2016, at 9:32 AM, plx via swift-evolution >> wrote: >> >> The issue addressed is real; I’m not sure this is the best approach. >> >> In particular, unless I’m missing something obvious,

Re: [swift-evolution] [Pitch] Refactor Metatypes

Is there a need of having this function at all? You always know the current static type locally. Sure one might need this in some generic function to extract the static type from an instance, but most of the time we could just write T.self to do that. If there really is a need for that

Re: [swift-evolution] [Proposal] Enums with stored properties

> On 12 Oct 2016, at 12:31, Karl via swift-evolution > wrote: > > I very much disagree with the proposal, and all of the things supporting it > (like deriving enums from other types and whatnot). I think you need to take > a step up from caring about whether it’s a

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 13, 2016, at 3:34 AM, Charles Srstka wrote: > >> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution >> > wrote: >> >>> On 12 Oct 2016, at 12:31, Karl via swift-evolution >>>

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution > wrote: > >> On 12 Oct 2016, at 12:31, Karl via swift-evolution >> > wrote: >> >> I very much disagree with the proposal, and all of the things

Re: [swift-evolution] private & fileprivate

> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution > wrote: > > >> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution >> > a écrit : >> >> On Oct 12, 2016, at 9:56 PM, Russ Bishop via

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

> On 11 Oct 2016, at 19:43, Erica Sadun via swift-evolution > wrote: > > I thought this was long gone but today I found out it is still legal: > > switch i { > case 4 ... 6: () > case 3: print("Here") > default: break > } > > Is there a motivating factor for

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

On 13 Oct 2016, at 11:06, Haravikk via swift-evolution wrote: > >> >> On 11 Oct 2016, at 19:43, Erica Sadun via swift-evolution >> > wrote: >> >> I thought this was long gone but today I found out it is

Re: [swift-evolution] [Proposal] Enums with stored properties

> On 13 Oct 2016, at 09:35, Charles Srstka wrote: > >> On Oct 13, 2016, at 3:34 AM, Charles Srstka > > wrote: >> >>> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution >>>

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

> On 13 Oct 2016, at 12:26, Alex Blewitt wrote: > > On 13 Oct 2016, at 11:06, Haravikk via swift-evolution > > wrote: >> >>> >>> On 11 Oct 2016, at 19:43, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

on Wed Oct 12 2016, Alexis wrote: > Just to clarify: It seems like the only ABI-affecting change here is the type > of keys/values. As you > note at the end of your proposal, this should just be > Dictionary.Keys/Dictionary.Values regardless > of whether we