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

+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 at 2:28 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > Introduction > > This proposal addresses significant unexpected performance

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

On Tue, Oct 11, 2016 at 8:21 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution < > swift-evolution@swift.org> wrote: > > > enum RectSize > { >let height:Int >let width:Int >case small(width:

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

Painful +1. I use the first one a whole lot in a project and it is going to get ugly. That said… I can see how it is tricky in a way that doesn't really pay off for most people. Removing the first feature might even be necessary for what I hope will ease the ugly. I don't see "Default generic

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

+1. I don't use this feature at all and (by extension) don't think there are many situations where it's useful. ~Robert Widmann 2016/10/11 18:03、Slava Pestov via swift-evolution のメッセージ: > I could if there’s interest. Since we intend on maintaining source >

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

> On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution > wrote: > > enum RectSize > { >let height:Int >let width:Int >case small(width: 30, height: 30) >case medium(width: 60, height: 60) >case large(width: 120, height: 120) > } I like

Re: [swift-evolution] stored properties in extensions

Interestingly, if all the stored properties defined in extensions could be determined at link-time, the size/layout of the side-table could include them directly, removing the need for further indirection. The offsets would still need to be fixed up, which would add some complexity to the

Re: [swift-evolution] Is there information about phases/versions/releases and scope?

> On Oct 11, 2016, at 4:48 PM, Xiaodi Wu via swift-evolution > wrote: > > Additional info for your reference: > > * Chris Lattner's original email on additional goals and non-goals for Swift > 4: >

Re: [swift-evolution] stored properties in extensions

Wow, that's a very interesting post. Sounds a lot simpler to implement than my idea about fixing up offsets in the linker and preserves binary compatability just the same. I got some complaints when I first started talking about this that the runtime would have to track extra pointers and

Re: [swift-evolution] Is there information about phases/versions/releases and scope?

Additional info for your reference: * Chris Lattner's original email on additional goals and non-goals for Swift 4: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html * Chris Lattner's speculation that Swift 3.x will be time-based: whatever's accepted for Swift 4

Re: [swift-evolution] Is there information about phases/versions/releases and scope?

As far as I know, there will be, but I'm not aware of new evolution proposals being accepted specifically for those releases. Perhaps core team folks can chime in. On Tue, Oct 11, 2016 at 18:31 Jay Abbott wrote: > So does that mean there's not going to be any 3.x versions

Re: [swift-evolution] Is there information about phases/versions/releases and scope?

So does that mean there's not going to be any 3.x versions between 3.0 and 4.0? On Tue, 11 Oct 2016 at 23:55 Xiaodi Wu wrote: > It's described in the swift-evolution GitHub repository readme: > > https://github.com/apple/swift-evolution > > > > On Tue, Oct 11, 2016 at 17:53

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

> On Oct 11, 2016, at 5:06 PM, Braeden Profile wrote: > > Awesome; +1. Does this address the lack of .init(keys:values:)? Would it > make that addition easier? No, I don't think this has any bearing on that question. There's a separate proposal for that sort of

Re: [swift-evolution] stored properties in extensions

> I think the language devs must have some idea how this will work, but > don't seem to want to share/discuss it at the moment. I was hoping for > some feedback about my implementation ideas - whether they are along the > right lines, or way off, or not necessary (because the implementation >

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

I agree. I like this proposal. -- E > On Oct 11, 2016, at 3:38 PM, Xiaodi Wu via swift-evolution > wrote: > > Very elegant solution. Strong +1; no other feedback comes to mind atm. > > > On Tue, Oct 11, 2016 at 4:28 PM, Nate Cook via swift-evolution >

Re: [swift-evolution] Is there information about phases/versions/releases and scope?

It's described in the swift-evolution GitHub repository readme: https://github.com/apple/swift-evolution On Tue, Oct 11, 2016 at 17:53 Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > I keep seeing it mentioned that some ideas are out of scope for Swift 4 > phase 1 - I

[swift-evolution] Is there information about phases/versions/releases and scope?

I keep seeing it mentioned that some ideas are out of scope for Swift 4 phase 1 - I understand from this list that phase 1 is to include any breaking changes then phase 2 (etc?) will be adding more features. That's all I know about it. It would be nice to know what phases are on the table and

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

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. -- | Mateusz Malczak +--- | mate...@malczak.info | http://malczak.info 2016-10-11 23:42 GMT+02:00 Braeden Profile

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

Awesome; +1. Does this address the lack of .init(keys:values:)? Would it make that addition easier? > On Oct 11, 2016, at 3:38 PM, Xiaodi Wu via swift-evolution > wrote: > > Very elegant solution. Strong +1; no other feedback comes to mind atm. > > > On Tue, Oct

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

As someone who's hit this performance issue myself, a big +1 from me. The solution looks like it fits perfectly into Swift. On Tue, Oct 11, 2016 at 3:01 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > Looks very nice. +1 here as well. > > On Oct 11, 2016, at 4:28

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

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 it? Slava > On Oct 11, 2016, at 1:58 PM, Pyry Jahkola

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

I agree Karl, especially the bit about the difficulty of implementation being the limiting thing here. I think the language devs must have some idea how this will work, but don't seem to want to share/discuss it at the moment. I was hoping for some feedback about my implementation ideas - whether

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

Looks very nice. +1 here as well. > On Oct 11, 2016, at 4:28 PM, Nate Cook via swift-evolution > wrote: > > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It introduces type-specific collections for a

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

Thank you for that clarification. I was confused about where it fitted in. I discuss it on swift-users. On Tue, Oct 11, 2016 at 2:51 PM, Chris Lattner wrote: > > > On Oct 11, 2016, at 2:34 PM, Tony Constantinides via swift-evolution < > swift-evolution@swift.org> wrote:

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

> On Oct 11, 2016, at 2:34 PM, Tony Constantinides via swift-evolution > wrote: > > Ok, > Any other feedback from the Swift community other than it does not belong as > part of Swift? Or get the hell out of here? > I discussing this issue so people in the Swift

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

Tony-- First off, welcome to the Swift community! Second, I think you're misunderstanding the feedback here. The swift-evolution list is not a mailing list for Swift community discussions in general. It's a mailing list for proposals to change the core language (how do generics work? how does

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

So, just to recap, the proposed solution is to help enums expose associated values via properties, and is not to create enums that are open to extra unnamed cases (RectSize(width:0,height:10))? What I see is that enums would still maintain their standing where an instance is just a selection

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

Very elegant solution. Strong +1; no other feedback comes to mind atm. On Tue, Oct 11, 2016 at 4:28 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It introduces

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

Ok, Any other feedback from the Swift community other than it does not belong as part of Swift? Or get the hell out of here? I discussing this issue so people in the Swift community are aware of what I am planning to do and have the ability to shape if they they so wish. Some Technical points

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

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 DictionaryKeys and DictionaryValues collections provide efficient key lookup and mutable

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

+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. > On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution > wrote: >

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

Reflection is likely to be tackled in Swift 5, no? So realistically, this could be on track for Swift 6 or 7. Let's postpone discussion until then. On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 11, 2016, at 12:40, Anton Zhilin via

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

> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution > wrote: > > Hello Ted, > First of all, this topic belongs to reflection, which is specifically stated > to be out of scope of Swift 4 Phase 1. So all considerations are purely > theoretical for now. >

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

I was reminded of this proposal which seems like an obvious win in clarity. Still planning to submit it, Slava? — Pyry > On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution > wrote: > > on Thu Jun 23 2016, Slava Pestov wrote: >

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

Fair enough. I defer to both of you. Thanks, -- E > On Oct 11, 2016, at 1:41 PM, Robert Widmann wrote: > > I agree, though it may seem counterintuitive at first. () is a value of unit > type that exists here to satisfy the sema’s requirements that all branches >

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

thank you, Goffredo, Anton, see inline TedvG > On 11 Oct 2016, at 21:10, Goffredo Marocchi wrote: > > I quite like your builder pattern way of adding properties and methods :). > > Sent from my iPhone > > On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution >

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

+1. I haven’t found use for it, and I don’t think there is one outside of stdlib. ~Robert Widmann > On Oct 10, 2016, at 6:12 PM, Erik Eckstein via swift-evolution > wrote: > > The purpose of ManagedBufferPointer is to create a buffer with a custom >

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

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 keeping this in the language? The compiler picks up on Void and emits an error. You'd think () would produce the same

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

> On Oct 11, 2016, at 8:26 AM, Xiaodi Wu via swift-evolution > wrote: > > The following document may inform your discussion here: > https://github.com/apple/swift/blob/73841a643c087e854a2f62c7e073317bd43af310/docs/proposals/Accessors.rst Specifically this section,

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

Dynamic Class/Struct Definition At Run Time At the time of this writing, 11 October 2016, it is not possible to define arbitrary classes, structs and maybe other entities dynamically at run time in Swift. I have some idea about it, expressed in this message. Creating class and other types

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

Hi, I think we are here discussing two different aspects of introducing this new feature - code syntax and underlying implementation. In terms of code syntax I would go with first proposal as it seems to me the simplest approach. When it comes to underlying implementation, I can imagine that

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

Oh, I see. I’m not sure about the dictionary one, that probably depends on whether the `Dictionary` type could use this addition to make member mutations O(1). The other example probably wouldn’t benefit from replacing the setter by a mutator, as there’s nothing to gain here - the

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

In case c) for example if your set implementation was something like this: set { _internalDict["propName"] = newValue } set { if newValue { _int |= SOME_BIT } else { _int &= ~SOME_BIT } } Could they be implemented as 'mutate'? On Tue, 11 Oct 2016 at 12:05 Jay Abbott wrote: >

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

actually scratch point a) - that's bloody obvious :D On Tue, 11 Oct 2016 at 11:58 Jay Abbott wrote: > This is interesting. I'm trying to evaluate your statement that "No setter > would be needed if a mutation clause is provided" but I can't think exactly > what the compiler

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

> On 11 Oct 2016, at 12:59, Jay Abbott wrote: > > This is interesting. I'm trying to evaluate your statement that "No setter > would be needed if a mutation clause is provided" but I can't think exactly > what the compiler would do in the case where there is a 'get' and

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

This is interesting. I'm trying to evaluate your statement that "No setter would be needed if a mutation clause is provided" but I can't think exactly what the compiler would do in the case where there is a 'get' and 'mutate', but no 'set'... a) when you call a non-mutating function; b) when you

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

Just having getters and setters doesn’t allow this (unless the optimiser is really smart about it). All the current API allows is grabbing whatever the `get` clause returns, mutating it, and then passing it into the `set` clause, whatever that does. The `set` clause might not do anything, or

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

This is the latest draft of the proposal: https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md Refactor Metatypes Proposal: SE–0126 Authors: Adrian Zubarev, Anton Zhilin, Brent Royal-Gordon Status: Revision Review manager:

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

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution > wrote: > > Right. The question is whether we *need* to add stored properties > out-of-module, and what the use case for that is. To me it seems that adding > them in-module is by far the more common

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

> On 11 Oct 2016, at 08:49, Benjamin Spratling wrote: > > Howdy, > The error message is not saying that aFunction throws, it says “??" might > throw. After all, you supplied a ()rethrows->(Int) to it as its second > argument, which is wrapping a ()throws->Int,

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

Howdy, The error message is not saying that aFunction throws, it says “??" might throw. After all, you supplied a ()rethrows->(Int) to it as its second argument, which is wrapping a ()throws->Int, “bFunction()" ?? and && and || wrap the trailing expression in an @autoclosure. I am a little

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

> On 11 Oct 2016, at 07:16, Karl wrote: > > You might expect this code to work: > > func aFunction() -> Int? { return 5 } > func bFunction() throws -> Int { return 4 } > > let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but > expression is not marked with a ‘try'

[swift-evolution] [Pitch] Change location of 'try' for infix operators

You might expect this code to work: func aFunction() -> Int? { return 5 } func bFunction() throws -> Int { return 4 } let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but expression is not marked with a ‘try' print(value) Instead, you must put the ‘try’ before the