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

2016-10-12 Thread Károly Lőrentey via swift-evolution
I believe the implementation of efficient in-place mutation is very explicit in the code -- it is done by implementing DictionaryValue’s subscript using a special “mutableAddressWithNativeOwner” addressor instead of a normal setter.

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

2016-10-12 Thread David Hart via swift-evolution
Hello Ted, Please try to understand. As Xiaodi and others have said a few times, it has nothing to do with the topic being important or interesting. The current phase of Swift 4’s development does not allow any extensive discussion or review on topics which do not impact ABI stability: Stage

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

2016-10-12 Thread Sean Heber via swift-evolution
> On Oct 12, 2016, at 3:10 PM, Xiaodi Wu wrote: > > On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber wrote: > > > With the improved syntax, this could look something like this instead: > > > > enum FileError: Error, LocalizedError { > > var url: URL {

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
Ah, well, I largely agree with you then. To get what you want, we don't need an ABI-breaking change. The proposal really is for nicer syntax. I can sympathize with that. But, the same argument you make about the evolution process could be said for any sugar that's out of scope at the moment, no?

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hi David, Thanks for your reply., OK, I think I understand. It then is a capacity problem, right? In effect, it means restricting people from bringing perhaps very valuable (not necessarily my contributions) and essential ideas forward, which could play a crucial role improving Swift. I

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

2016-10-12 Thread Kevin Nattinger via swift-evolution
> On Oct 12, 2016, at 12:25 PM, Charles Srstka wrote: > >> On Oct 12, 2016, at 12:32 PM, Kevin Nattinger via swift-evolution >> > wrote: >> >> or more like a body (some different options for syntax, pick

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

2016-10-12 Thread Karl via swift-evolution
> My point is that, IMO, this is all I want. Thus what I’m implying is that > there’s probably not any ABI impact to (IMO) “fix” enums with associated > values, and so I don’t know why this discussion keeps going on and veering > into (what seems to me to be) overly complex territory when many

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 4:21 PM, Karl wrote: > > My point is that, IMO, this is all I want. Thus what I’m implying is > that there’s probably not any ABI impact to (IMO) “fix” enums with > associated values, and so I don’t know why this discussion keeps going on > and veering

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

2016-10-12 Thread David Hart via swift-evolution
Hi Ted, My replies inline: > On 12 Oct 2016, at 22:37, Ted F.A. van Gaalen wrote: > > Hi David, > > Thanks for your reply., OK, I think I understand. > > It then is a capacity problem, right? Mainly. We lived through a few months where there was very little focus,

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hi David, > > Thanks for your reply., OK, I think I understand. > > It then is a capacity problem, right? > > In effect, it means restricting people from bringing perhaps very valuable >

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

2016-10-12 Thread Charles Srstka via swift-evolution
> On Oct 12, 2016, at 3:07 PM, Karl wrote: > > I disagree. I find the first better in a number of respects (although there > are certainly things you could do to optimise legibility). > > Firstly, I can more clearly see all of the various file errors. I can easily > see

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

2016-10-12 Thread Dave Abrahams via swift-evolution
on Tue Oct 11 2016, Károly Lőrentey wrote: > +1 > > ManagedBuffer has been really useful a couple of times, but I never > found a use for ManagedBufferPointer. I can’t even say I’m entirely > sure what need it was originally designed to fulfill. The real need is/was

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

2016-10-12 Thread Karl via swift-evolution
You can already use structs as raw types. You just have to implement the RawRepresentable conformance yourself. RawRep doesn’t affect the enum’s storage, and the shorthand syntax we’ve got saying “case a = 42” and so on is just for the compiler to synthesise a couple of switch statements. The

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

2016-10-12 Thread Mateusz Malczak via swift-evolution
> Mateusz, you lost me with “store some extra data”. > Does that mean something extra besides the code that Braeden suggested? What I meant by “store some extra data” was, to be able to define immutable properties of any type, as a part of enum instead of defining getters witch switches. I think

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

2016-10-12 Thread Rien via swift-evolution
I read Braeden’s example such that this proposal is in reality “just” syntactic sugar. AFAIAC it does not change how enums are implemented after compilation. Like sugar, it makes working with enums clearer and therefore easier. All initialisation values are defined right there with the ‘case’

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hi Jeremy > On 12 Oct 2016, at 10:52, Jeremy Pereira > wrote: > > >> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution >> wrote: >> >> >> While Swift is mainly a statically typed language, recompilation or >>

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

2016-10-12 Thread Jean-Denis Muys via swift-evolution
A clear win for me. +1 > On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution > wrote: > > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It introduces type-specific collections for a Dictionary >

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

2016-10-12 Thread T.J. Usiyan via swift-evolution
+1 from me. Seems like a solid change. On Wed, Oct 12, 2016 at 12:39 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > +1. Haven't hit this issue personally, but I agree it's important and the > proposed solution seems like the right fix. > > On Tue, Oct 11, 2016

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

2016-10-12 Thread Mateusz Malczak via swift-evolution
I agree, we dont event have to add a new language syntax to get this feature. Using structs as rawTypes would do the trick but 1. it should be possible to use struct initializer to define enum cases struct MyStruct { var width: Int var height: Int init(width: Int, height: Int) { ... } } enum

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

2016-10-12 Thread Jeremy Pereira via swift-evolution
> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution > wrote: > > > While Swift is mainly a statically typed language, recompilation or > additional > compilation and somehow link it al together is obviously necessary at run > time, > each time a

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

2016-10-12 Thread Stephan Knitelius via swift-evolution
+1 On Wed, 12 Oct 2016 at 09:09 Said Sikira via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > > On October 12, 2016 at 8:54:45 AM, Rien via swift-evolution ( > swift-evolution@swift.org) wrote: > > Beautiful, +1 > > Rien > > > On 11 Oct 2016, at 23:28, Nate Cook via

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

2016-10-12 Thread J.E. Schotsman via swift-evolution
> On 12 Oct 2016, at 09:41,Mateusz Malczak wrote: > > That's exactly what this proposal is about. I would like to > keep all enum properties but add an extra feature, so that enums can > store some extra data. If technically possible I would prefer to directly use types for enum cases. Reducing

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 10:07 AM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > Not at all - his proposal looks like the enum cases have an associated > value, when that is exactly what you _don’t_ want. It’s wasted storage > because they have a handful of known values. > > It’s

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

2016-10-12 Thread Nate Cook via swift-evolution
Thanks for your feedback! Response below. > On Oct 12, 2016, at 5:40 AM, Daniel Vollmer via swift-evolution > wrote: > > Hi, > > I very much think the points mentioned in the motivation are worth addressing > (and IMO this is not an area where “maybe the optimizer

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

2016-10-12 Thread Kevin Nattinger via swift-evolution
As long as I can use the syntax in Braeden's example, I don't really care how it's implemented, as sugar for some ugly getters or actual stored values. > On Oct 12, 2016, at 04:52, Rien via swift-evolution > wrote: > > I read Braeden’s example such that this

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

2016-10-12 Thread Karl via swift-evolution
Not at all - his proposal looks like the enum cases have an associated value, when that is exactly what you _don’t_ want. It’s wasted storage because they have a handful of known values. It’s a PITA, I get it, I go through it all the time, too; but really this is the very definition of a

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

2016-10-12 Thread Nate Cook via swift-evolution
> 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, the ownership strategy > here would have to be: > > -

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

2016-10-12 Thread Karl via swift-evolution
I think he wants convenience accessors for the associated values; the problem is that in his example, he shouldn’t even be using associated values at all. The example was about getting a size (a pair of numbers) based on the case of an enum. In that case, you need to write a switch statement to

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
> On 11 Oct 2016, at 23:04, Xiaodi Wu wrote: > > Reflection is likely to be tackled in Swift 5, no? I'd think you don’t need reflection that much, because defining dynamic classes (and other entities) are solely incremental compiler tasks, for which it can use previously

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen wrote: > > On 11 Oct 2016, at 23:04, Xiaodi Wu wrote: > > Reflection is likely to be tackled in Swift 5, no? > > > I'd think you don’t need reflection that much, because defining > dynamic classes

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

2016-10-12 Thread Karl via swift-evolution
I disagree. I find the first better in a number of respects (although there are certainly things you could do to optimise legibility). Firstly, I can more clearly see all of the various file errors. I can easily see how many there are, which associated values they take, etc. That’s important

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber wrote: > > > With the improved syntax, this could look something like this instead: > > > > enum FileError: Error, LocalizedError { > > var url: URL { get } > > > > case notFound(url: URL) { > > errorDescription =

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

2016-10-12 Thread Rien via swift-evolution
I’d give a +1 for the suggestion of Braeden. Mateusz, you lost me with “store some extra data”. Does that mean something extra besides the code that Braeden suggested? Rien. > On 12 Oct 2016, at 00:13, Mateusz Malczak via swift-evolution > wrote: > > That's exactly

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

2016-10-12 Thread Dave Abrahams via swift-evolution
on Tue Oct 11 2016, Slava Pestov wrote: > I could if there’s interest. Since we intend on maintaining source > compatibility, it will not result in a simpler implementation, though, > since we’ll need to keep the old code path around for Swift 3 > mode. Still worth

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

2016-10-12 Thread Said Sikira via swift-evolution
+1 On October 12, 2016 at 8:54:45 AM, Rien via swift-evolution ( swift-evolution@swift.org) wrote: Beautiful, +1 Rien > On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > > Introduction > > This proposal addresses significant unexpected performance

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

2016-10-12 Thread Károly Lőrentey via swift-evolution
Ah, I see plx has already brought this up. So this is a bug in the implementation, and (presumably) DictionaryValue’s mutable subscript addressor is supposed to take care of COW semantics without introducing needless copying. (It’s too bad we aren’t supposed to use these magical addressors

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

2016-10-12 Thread Mateusz Malczak via swift-evolution
I got a bit confused, I think we are here talking about completely different features. Lets take a look at example from Karl > enum Something { >case oneThing(UIView) >case anotherThing(Error) >case yetAnotherThing(Int) > } > > …which is dangerously similar to Braeden’s example,

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

2016-10-12 Thread Károly Lőrentey via swift-evolution
I think this is a lovely approach to solving this API design problem. One thing I don’t quite understand yet is how these kinds of mutable views interact with copy on write semantics. COW rules can be subtle, and these views seem to put an extra twist on top that seems hard to

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

2016-10-12 Thread Austin Zheng via swift-evolution
This is utterly ridiculous. Chris Lattner and the other core team members posted repeatedly at the beginning of the Swift 3.x/4 development cycle asking us expressly to keep the discussion focused on a number of specific topics. Not only have you repeatedly ignored that request, now you are being

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hi David, thanks for your explanation, most things are understandable. However, I am challenged by all this to study this subject more in detail and come back with it later at a more convenient time. After all those years, now I have time for this to go in-depth, wait and see. Met

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

2016-10-12 Thread plx via swift-evolution
I agree that at least for stdlib purposes there’s something that looks like an explicit choice to make in-place mutation *available*. What I was trying to explain is whether or not in-place mutation *happens* is a bit implicit. It’s one thing to say that the difference here is just an idiom

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

2016-10-12 Thread Mateusz Malczak via swift-evolution
> RawRep is two things: a failable initialiser, and a getter. > When the compiler synthesises them, it generates those > exact same switch statements I proposed before. It’s quite > simple, and there are potential issues to allowing arbitrary > structs to use the same system. For one thing, they

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hi Xiaodi, thanks for you reply, yes, I am aware from most things you write here, and also that what I wrote about dynamic facilities is probably not unique, as there are so many people involved and interested etc. then you wrote > … Swift 3, but the truth is that there will never be a release

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

2016-10-12 Thread Charles Srstka via swift-evolution
> On Oct 12, 2016, at 4:48 PM, Charles Srstka via swift-evolution > wrote: > > Since the definitions of the properties are implementation details, the > generated interface would collapse to the simple list of cases and their > associated values, just as methods,

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hi Xiaodi, please read in-line, thank you. > On 12 Oct 2016, at 15:58, Xiaodi Wu wrote: > > On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen > wrote: > >> On 11 Oct 2016, at 23:04, Xiaodi Wu

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

2016-10-12 Thread Alexis via swift-evolution
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 implement this proposal or not, in which case this can be punted for Swift 4. It

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 10:31 AM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > Thanks for your feedback! Response below. > > On Oct 12, 2016, at 5:40 AM, Daniel Vollmer via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi, > > I very much think the points

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

2016-10-12 Thread Xiaodi Wu via swift-evolution
On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen wrote: > Hi Xiaodi, > please read in-line, thank you. > > On 12 Oct 2016, at 15:58, Xiaodi Wu wrote: > > On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen < > tedvgios...@gmail.com> wrote: > >>

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

2016-10-12 Thread Nate Cook via swift-evolution
> On Oct 12, 2016, at 10:58 AM, Károly Lőrentey via swift-evolution > wrote: > > I think this is a lovely approach to solving this API design problem. > > One thing I don’t quite understand yet is how these kinds of mutable views > interact with copy on write

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Dear Xiaoid I still don’t agree with you, there should be some flexibility, things should live and also, if we adhere to this list you refer to on Github, than no new topics would be discussable... I am sorry if I wrote a bit harsh to you. Kind Regards 尊敬的 Ted > On 12 Oct 2016, at 18:41,

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

2016-10-12 Thread Ted F.A. van Gaalen via swift-evolution
Hello Austin I haven’t read that from Chris - Must have overlooked it due to the shear volume on swift-evolution. Note that as you can see, I have apologised to Xiaodi for being a bit too direct, such as perceived in your culture perhaps. The Chinese characters should mean “respectful”” btw.

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

2016-10-12 Thread plx via swift-evolution
Thanks for the quick reply; given that I’m quite wrong about the important mechanics I rescind my criticisms. I will say I care about this enough to reply because the inability to do in-place mutation of dictionary values has been an incredibly frustrating limitation and I’d just assumed the

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

2016-10-12 Thread Russ Bishop via swift-evolution
> On Oct 11, 2016, at 2:28 PM, Nate Cook via swift-evolution > wrote: > > Inefficient > Value Mutation > > Dictionary values can be modified through the keyed

Re: [swift-evolution] private & fileprivate

2016-10-12 Thread Russ Bishop via swift-evolution
> On Oct 10, 2016, at 9:59 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution >> > wrote: >> >>> >>> On Oct 7, 2016, at 15:15, William

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

2016-10-12 Thread Russ Bishop via swift-evolution
> On Oct 11, 2016, at 12:26 AM, Adrian Zubarev via swift-evolution > wrote: > > This is the latest draft of the proposal: > https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md > >

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

2016-10-12 Thread Dave Abrahams via swift-evolution
on Tue Oct 11 2016, Nate Cook wrote: > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It > introduces type-specific collections for a Dictionary instance's keys and > values properties. > > New

Re: [swift-evolution] private & fileprivate

2016-10-12 Thread Chris Lattner via swift-evolution
On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution wrote: >>> I actually consider it very lucky that most of our changes so far have been >>> fairly non-controversial. Everybody has a different idea of what would make >>> Swift a better language, and all of

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

2016-10-12 Thread Chris Lattner via swift-evolution
> On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hello Austin > I haven’t read that from Chris - Must have overlooked it due to the shear > volume on swift-evolution. Completely understandable, I’m sure you’re not the only one