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

Maybe I am missing something, but is this what you want? class Size { let width: Double let height: Double init(width: Double, height: Double) { … } } enum Format { case SMALL case MEDIUM case LARGE var size: Size { switch self {

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

> Is this what you're trying to achieve, only using a nicer syntax to > represent it? > http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831 Yes This similar to example shown in my original email, where struct is used as a rawType and custom string literal parsing to assign values to

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

> On 10 Oct 2016, at 13:04, Mateusz Malczak via swift-evolution > wrote: > > I think, I have used quite unfortunate naming, which is a root of an > misunderstanding here. By saying 'enums with stored properties' what I > was really thinking about, was enumeration

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

Is this what you're trying to achieve, only using a nicer syntax to represent it? http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831 On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak wrote: > I think, I have used quite unfortunate naming, which is a root of an >

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

> On Oct 10, 2016, at 1:13 PM, Jay Abbott wrote: > > I understand Charlie. A few points though: > a) I'm talking about pure Swift, this is absolutely nothing to do with > Objective-C; Sure, but in either case you will need to somehow solve locking of the structure holding

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

Thanks for the explanation Mateusz, I think I understand. So the enum still only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some properties? So some code to use it might be: var aFormat = Format.LARGE aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change

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

I think, I have used quite unfortunate naming, which is a root of an misunderstanding here. By saying 'enums with stored properties' what I was really thinking about, was enumeration type with stored constant, immutable properties (constants). I don't want to duplicate 'struct' type here, but

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

I understand Charlie. A few points though: a) I'm talking about pure Swift, this is absolutely nothing to do with Objective-C; b) If you read back on the AO thread you'll see that initially I was thinking "I want AO because it will give me stored properties in extensions" when really I should have

Re: [swift-evolution] private & fileprivate

I don't find this example persuasive, because: 1125 LOC is on the long side for a single file, but not by any means "thousands" of LOC. In any case, having hacked on corelibs-foundation myself, my sense is that its files are organized in such a way that NSDecimal would be expected to be

Re: [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

> On Oct 9, 2016, at 1:10 PM, Erica Sadun via swift-evolution > wrote: > > Normally in guard and if condition lists, you look up a value in a dictionary > and conditionally cast: > > if let value = dict[key] as? T, ... > > The "as?" operator passes the Any?

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

> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote: > > t a good illustration of what I would like to be able to define with > my proposed feature. > But instead to creating a class/struct to in switch case I would like > enumeration type to be able to carry that information within its cases

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

Also, just to be clear, (unfortunately) the enum ship has sailed and I don’t think we’ll get a rename/split to union, it’s just that the functionality of associated objects is conceptually closer to what other languages call a union. I would, however, like the ability to use an enum in the

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

I agree wholeheartedly. An enum case should be a compile-time constant. IMO, “enums” with associated values should properly be a separate entity, called “union” as that’s essentially what they are. > On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution >

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

By imposing that kind of separation you leave an entire class of generic and structural programming patterns off the table. An enumeration is not just an enumeration of constants, it is an enumeration of data, and data takes far more useful forms than just bitfields - similarly when it does

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

> On Oct 9, 2016, at 9:45 PM, Tony Constantinides via swift-evolution > wrote: > > In Swift 3.0 you can build Android apps in Linux but only console apps as > there is no framework to build GUI apps using JNI. > What I propose is to build an initial limited

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

Its a nice cop-out, but this framework is an extension of the standard library of Swift as it will allow Swift developers to target new mobile platforms. This is the mailing lists for the evolution of Swift which is what this is. I not sure any of the other Swift mailing lists suits this goal. I

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

> On Oct 10, 2016, at 11:30 AM, Robert Widmann wrote: > > By imposing that kind of separation you leave an entire class of generic and > structural programming patterns off the table. An enumeration is not just an > enumeration of constants, it is an enumeration of

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

This is the way Java enumerations work. https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html I think it is a good model, and I think Swift enumerations should also work the same way. An enumeration is a finite set of things. It’s really inconvenient to have to limit those things to

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

It’s disappointing that you seem not to understand what this mailing list is for. Building a Framework does not require the evolution process. It’s all up to you to open a GitHub repository and just start building. Sure you can ask for help, but I believe other platforms like stackoverflow or

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

I haven’t followed the whole topic, but I myself always wished for stored properties on Swift enums. I’d like to throw an idea in the room. How about to a two type enums? By that I mean something like this: enum Enum : RawType, StoreType { case a = (rawInstance1, storeInstance1) case b

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On Oct 8, 2016, at 10:01 PM, Jon Shier via swift-evolution > wrote: > > It’s not that nobody cares, it’s that it’s ultimately up to Apple to decided > how this is going to go, and nobody there seems to care. Until a decision is > made there, nothing will happen.

Re: [swift-evolution] private & fileprivate

> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution > wrote: > >> >> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >> > wrote: >> >> >>> On Oct 7, 2016, at 3:05 PM, Zach

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

> On Oct 10, 2016, at 2:04 PM, Tony Constantinides via swift-evolution > wrote: > > Its a nice cop-out, but this framework is an extension of the standard > library of Swift Then it requires a proposal as much. Bear in mind that the Swift Standard Library is

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

> How about to a two type enums? By that I mean something like this: > > enum Enum : RawType, StoreType { > case a = (rawInstance1, storeInstance1) > case b = (rawInstance2, storeInstance2) > case c = rawInstance3, storeInstance3 // or not tuple like? > } > > let instance = Enum.a >

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

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 use case, for the purposes of implementing protocols. At any rate, the rewrite option would be a great

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

Yes, there are valid use cases. For example, in case of many UI elements, you do not have control over their instantiation and need to associate a "help description" with them as an example. Which can be done by an additional property helpDescription added to NSView/UIView. Another example

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

Ok, I was trying to follow the evolution process which states to "discuss your idea on the mailing lists" before i begin work on it.That is what I am doing. If you feel this work is not part of swift-evolution I shall bother this group no longer. You have to remember I am very new to interfacing

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

> On 10 Oct 2016, at 14:36, Mateusz Malczak wrote: > >> Can't this problem most easily be solved by a raw value? Like so: >> >> enum Format : Int { >>case small = 30 >>case medium = 60 >>case large = 120 >> >>var width:Int { return self.rawValue } >>

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

> I know, but what I'm saying is that this problem could be solved in the > multiple values case by allowing tuples as raw values for enums, since that > would allow you to specify both width and height. So it'd look something > like this: We have three different possible solution 1. stored

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

on Mon Oct 10 2016, Tony Constantinides wrote: > Its a nice cop-out, but this framework is an extension of the standard > library of Swift as it will allow Swift developers to target new mobile > platforms. It's not a cop-out. We would never include UIKit in

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

I just did a quick summary of this discussion and get all ideas and code examples in one place - https://github.com/malczak/enums-with-stored-properties I will try to keep that document updated, but feel free to edit it as well -- | Mateusz Malczak 2016-10-10 21:18 GMT+02:00 Haravikk

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

> On 10 Oct 2016, at 21:18, Haravikk via swift-evolution > wrote: > > >> On 10 Oct 2016, at 14:36, Mateusz Malczak > > wrote: >> >>> Can't this problem most easily be solved by a raw value? Like so: >>> >>> enum

Re: [swift-evolution] Automatic generation of initializer including default values

We considered a proposal I wrote early in the year. There was extensive discussion of the topic at that time. The core team decided to defer the topic at the time. Everyone was convinced there are better ways to handle it than I originally proposed (including myself). The topic will be

Re: [swift-evolution] private & fileprivate

On Oct 8, 2016, at 12:15 PM, Matthew Johnson via swift-evolution wrote: > > There are rather significant optimization barriers at module boundaries right > now. These do not exist for the standard library due to its tight > relationship with the compiler, but for

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

I would be amenable to that IF we can skip the `.rawValue`, which is, IMO, ugly and repetitive. > On Oct 10, 2016, at 11:54 AM, J.E. Schotsman via swift-evolution > wrote: > > >> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote: >> >> t a good illustration of what I

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

For simple structs this is already possible (see this example: https://swiftlang.ng.bluemix.net/#/repl/57fb8e3e4f9bcf25fdd415cd). If we focus on more complex cases where properties of Any? type are allowed I think this approach could do the trick... but still I would like to be able to access

[swift-evolution] Parameter names in closures in Swift 3 are no longer possible

I’ve been a little dismayed to see that closures in Swift 3 no longer have parameter names. As an example, in Swift 2, a function with a completion block may look like this: func sendMessage(completion: (success: Bool, recipientID: String?, senderID: String?) -> Void) { //Oh no it failed

[swift-evolution] Automatic generation of initializer including default values

Hi, When I am defining a struct I find myself often using a style as shown in the following example: struct Foo { var greeting: String var x: Int var y: Int var z: Int init(greeting: String, x: Int = 1, y: Int = 2, z: Int = 3) {

Re: [swift-evolution] Automatic generation of initializer including default values

I'm ambivalent here. I know this is convenient, but I have a stronger interest in controlling my APIs, initializers included. The more the compiler synthesizes, the less control I have and the more code I have to write to make up for that. I don't think there's enough here (yet?) to justify

Re: [swift-evolution] Parameter names in closures in Swift 3 are no longer possible

As mentioned previously, the core team has laid out a two-step roadmap to restoring parameter names: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html On Mon, Oct 10, 2016 at 10:55 Andrew Hart via swift-evolution < swift-evolution@swift.org> wrote: > I’ve been a

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

Hi, Im currently using similar structure in my projects. But every time I use this kind of code to carry over some extra information with enum cases I see it as a walk-around for language limitation. Enumeration type in swift is already powerful with associated values and rawValues. If you look at

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

Perhaps it is a bit ugly, but I don’t know if allowing stored properties on enums is the solution: that looks very ugly to me too. > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution > wrote: > > I would love to be able to have stored properties in addition

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

Hi, > Perhaps it is a bit ugly, but I don’t know if allowing stored properties on > enums is the solution: that looks very ugly to me too. That may look ugly, but can be very useful, if only you think rawValue's are useful then you should also agree that stored properties would be useful :) -- |

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

Hi Jay, > To me, "Enumeration defines a type with well defined set of possible values" > seems to contradict the idea of having properties that can have different > values. I think its more about the way you see enumeration type. In most cases enum cases just carry over some information. When you

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

> On 10 Oct 2016, at 20:34, Mateusz Malczak wrote: > >> I know, but what I'm saying is that this problem could be solved in the >> multiple values case by allowing tuples as raw values for enums, since that >> would allow you to specify both width and height. So it'd look

[swift-evolution] [Pitch] deprecating ManagedBufferPointer

The purpose of ManagedBufferPointer is to create a buffer with a custom class-metadata to be able to implement a custom deinit (e.g. to destroy the tail allocated elements). It was used in Array (before I replaced it with the new tail-allocated-array-built-ins). But now it’s not used anymore in

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

There have been many instances where unexpected bad performance was caused by the interplay between getters, setters, mutations and the copy-on-write mechanism. For example: struct Foo { private var _array: [Int] = [1, 2, 3, 4, 5] var array: [Int] { get { return _array }

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

> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution > wrote: > > There have been many instances where unexpected bad performance was caused by > the interplay between getters, setters, mutations and the copy-on-write > mechanism. For example: > >

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > > wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile

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

> Can't this problem most easily be solved by a raw value? Like so: > > enum Format : Int { > case small = 30 > case medium = 60 > case large = 120 > > var width:Int { return self.rawValue } > var height:Int { return self.rawValue } > } This only solves a problem when

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

> Maybe I am missing something, but is this what you want? It a good illustration of what I would like to be able to define with my proposed feature. But instead to creating a class/struct to in switch case I would like enumeration type to be able to carry that information within its cases For

[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

Hey guys and girls and everything in between, I was discussing this on Twitter. Perhaps the first step to easing this import system is to allow import conditional operators: && || would be the two of most use (mostly ||). We could perform the Darwin or Glibc import based on order of