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

[Maximilian Hünenberger via swift-evolution]

I think your second point is quite interesting!

We should consider expanding this so that we can get any associated value:

// from the Swift book
enum Barcode {
case upc(Int, Int, Int, Int)
case qrCode(String)
}

let code = Barcode.upc(9,2,3,4)
if let upcCode = code.upc {
// upcCode: (Int, Int, Int, Int)
upcCode.0 // 9 : Int
}
// direct access
code.upc?.0 // 9 : Int?


This would also increase performance if the following example is not optimized:

enum Term {
case sum([Term])
case number(Double)
}

var term = Term.sum([..., ..., ...])
// appending an element to the array
if var .sum(array) = term {
// in the worst case the whole array will be copied
array.insert(.number(1.0) at: 0)
term = .sum(array)
} else {
fatalError()
}

// in contrast the proposed version
// here you are sure that the array won't be copied
term.sum!.insert(.number(1.0), at: 0)


I don't know wether this impacts ABI so I would defer this idea if not.

Best regards
Maximilian

> Am 12.10.2016 um 13:22 schrieb 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 MyEnum: MyStruct
> {
> case myStructCase1(width: 30, height: 30)
> case myStructCase2(width: 60, height: 60)
> ...
> }
> 
> 2. calling .rawVaue should not be required in such case to access
> stored properties
> 
> let e = MyEnum.myStructCase1
> let width = e.width // instead of e.rawValue.width
> 
> Immutability of all properties in enum struct type is already
> implemented in Swift.
> At the same time .rawValue stays as it is for primitive types.
> 
> --
> | Mateusz Malczak
> +---
> 
> 
> 2016-10-12 13:02 GMT+02:00 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 a type to a tuple loses the computed properties and methods of the
>> type.
>> The types must be equatable I suppose.
>> 
>> The current enum rawValues are just indexes or keys which the compiler can
>> autogenerate (like it does for enums without a raw type).
>> Of course the raw values can be used in some smart way, like for sorting or
>> grouping cases, but this can all be done with general types - and better at
>> that.
>> 
>> So basically you have a struct type and an enum which is just a set of
>> static lets of the struct type.
>> struct MyStruct {}
>> enum MyEnum: MyStruct
>> {
>> case myStruct1
>> case myStruct2
>> ...
>> }
>> 
>> MyStruct need not be created specifically for the enum; it might be useful
>> on its own.
>> MyEnum can have additional computed properties and methods which are needed
>> for the enumerated values only.
>> 
>> The cases can be accessed like MyStruct instances. No need for .rawValue
>> except in the case of primitive types. Even there there is room for sugar
>> (if a variable is already known to be of type Int we can assign an enum:Int
>> case to it with implied .rawValue).
>> 
>> Jan E.
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kenny Leung via swift-evolution]

I’ve wondered this for a while now. Why must enums implement RawRepresentable?

-Kenny


> On Oct 12, 2016, at 4:37 AM, Karl via swift-evolution 
>  wrote:
> 
> 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 only reason the type needs to be a 
> string/integer literal in that case is so that we can check uniqueness and 
> solve the most common case. If you write your own implementation, you can 
> handle the more nuanced stuff there.
> 
> I don’t think there are any restrictions at all on RawRepresentable.RawType 
> (not even Comparable). It can be anything you like.
> 
> Karl
> 
>> On 12 Oct 2016, at 13:22, Mateusz Malczak via swift-evolution 
>>  wrote:
>> 
>> 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 MyEnum: MyStruct
>> {
>> case myStructCase1(width: 30, height: 30)
>> case myStructCase2(width: 60, height: 60)
>> ...
>> }
>> 
>> 2. calling .rawVaue should not be required in such case to access
>> stored properties
>> 
>> let e = MyEnum.myStructCase1
>> let width = e.width // instead of e.rawValue.width
>> 
>> Immutability of all properties in enum struct type is already
>> implemented in Swift.
>> At the same time .rawValue stays as it is for primitive types.
>> 
>> --
>> | Mateusz Malczak
>> +---
>> 
>> 
>> 2016-10-12 13:02 GMT+02:00 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 a type to a tuple loses the computed properties and methods of the
>>> type.
>>> The types must be equatable I suppose.
>>> 
>>> The current enum rawValues are just indexes or keys which the compiler can
>>> autogenerate (like it does for enums without a raw type).
>>> Of course the raw values can be used in some smart way, like for sorting or
>>> grouping cases, but this can all be done with general types - and better at
>>> that.
>>> 
>>> So basically you have a struct type and an enum which is just a set of
>>> static lets of the struct type.
>>> struct MyStruct {}
>>> enum MyEnum: MyStruct
>>> {
>>> case myStruct1
>>> case myStruct2
>>> ...
>>> }
>>> 
>>> MyStruct need not be created specifically for the enum; it might be useful
>>> on its own.
>>> MyEnum can have additional computed properties and methods which are needed
>>> for the enumerated values only.
>>> 
>>> The cases can be accessed like MyStruct instances. No need for .rawValue
>>> except in the case of primitive types. Even there there is room for sugar
>>> (if a variable is already known to be of type Int we can assign an enum:Int
>>> case to it with implied .rawValue).
>>> 
>>> Jan E.
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 
>>> > 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 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 struct or enum and think 
 about what you are trying to model; that will guide you towards the 
 correct type(s) to use.
 
 You have only shown a handful of fixed size values, so I would suggest a 
 computed property in your case:
 
 enum FixedSize {
  case small
  case medium
  case large
 
  struct Size { let width : Int; let height: Int }
 
  var size : Size {
switch self {
case .small: return Size(width: 30, height: 30)
// … etc
}
  }
 }
 
 There is no need for these sizes to be stored at all. If you want them 
 baked in to your enum’s values, clearly you expect them to be specific 
 values. It’s more efficient to just drop the stored data altogether in 
 this case; this enum will get lowered in to single byte, which is more 
 efficient to store and transport.
 
 Karl
>>> 
>>> Actually this is why I pointed to .rawValue as the solution; you're still 
>>> using a lot of boiler-plate to implement the computed property via a 
>>> switch; I don't know how well Swift optimises that, but if it actually runs 
>>> the switch each time it's not ideal, plus if you have a lot of enum cases 
>>> then it becomes increasingly burdensome to maintain when the values aren't 
>>> set alongside the cases themselves.
>>> 
>>> It's certainly one way to do it, but like I said .rawValue enables the size 
>>> to be set alongside each case, and pulled out much more cleanly, the only 
>>> problem is that you can't use tuples as a raw value, meanwhile conforming 
>>> to RawRepresentable can involve a lot more boiler plate overall (though 
>>> once done it works quite nicely), it's just overkill for any situation 
>>> where a tuple would do.
>>> 
>>> Again, if we had tuples for raw values we could easily do:
>>> 
>>> enum Format : (width:Int, height:Int) {
>>> case small = (30, 30)
>>> case medium = (60, 60)
>>> case large = (120, 120)
>>> 
>>> var width:Int { return self.rawValue.width }
>>> var height:Int { return self.rawValue.height }
>>> }
>> 
>> Raw values are not a general solution, though, since enums with associated 
>> types can’t have them.
>> 
>> Charles
> 
> *associated values.

Can anyone clarify why not? This doesn't seem like two things that are mutually 
exclusive, so the fix there could be allowing raw values on enums with 
associated values as well?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 
>>> > 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 struct or enum and think 
>>> about what you are trying to model; that will guide you towards the correct 
>>> type(s) to use.
>>> 
>>> You have only shown a handful of fixed size values, so I would suggest a 
>>> computed property in your case:
>>> 
>>> enum FixedSize {
>>>  case small
>>>  case medium
>>>  case large
>>> 
>>>  struct Size { let width : Int; let height: Int }
>>> 
>>>  var size : Size {
>>>switch self {
>>>case .small: return Size(width: 30, height: 30)
>>>// … etc
>>>}
>>>  }
>>> }
>>> 
>>> There is no need for these sizes to be stored at all. If you want them 
>>> baked in to your enum’s values, clearly you expect them to be specific 
>>> values. It’s more efficient to just drop the stored data altogether in this 
>>> case; this enum will get lowered in to single byte, which is more efficient 
>>> to store and transport.
>>> 
>>> Karl
>> 
>> Actually this is why I pointed to .rawValue as the solution; you're still 
>> using a lot of boiler-plate to implement the computed property via a switch; 
>> I don't know how well Swift optimises that, but if it actually runs the 
>> switch each time it's not ideal, plus if you have a lot of enum cases then 
>> it becomes increasingly burdensome to maintain when the values aren't set 
>> alongside the cases themselves.
>> 
>> It's certainly one way to do it, but like I said .rawValue enables the size 
>> to be set alongside each case, and pulled out much more cleanly, the only 
>> problem is that you can't use tuples as a raw value, meanwhile conforming to 
>> RawRepresentable can involve a lot more boiler plate overall (though once 
>> done it works quite nicely), it's just overkill for any situation where a 
>> tuple would do.
>> 
>> Again, if we had tuples for raw values we could easily do:
>> 
>> enum Format : (width:Int, height:Int) {
>> case small = (30, 30)
>> case medium = (60, 60)
>> case large = (120, 120)
>> 
>> var width:Int { return self.rawValue.width }
>> var height:Int { return self.rawValue.height }
>> }
> 
> Raw values are not a general solution, though, since enums with associated 
> types can’t have them.
> 
> Charles

*associated values.

Charles___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 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 struct or enum and think about 
>> what you are trying to model; that will guide you towards the correct 
>> type(s) to use.
>> 
>> You have only shown a handful of fixed size values, so I would suggest a 
>> computed property in your case:
>> 
>> enum FixedSize {
>>  case small
>>  case medium
>>  case large
>> 
>>  struct Size { let width : Int; let height: Int }
>> 
>>  var size : Size {
>>switch self {
>>case .small: return Size(width: 30, height: 30)
>>// … etc
>>}
>>  }
>> }
>> 
>> There is no need for these sizes to be stored at all. If you want them baked 
>> in to your enum’s values, clearly you expect them to be specific values. 
>> It’s more efficient to just drop the stored data altogether in this case; 
>> this enum will get lowered in to single byte, which is more efficient to 
>> store and transport.
>> 
>> Karl
> 
> Actually this is why I pointed to .rawValue as the solution; you're still 
> using a lot of boiler-plate to implement the computed property via a switch; 
> I don't know how well Swift optimises that, but if it actually runs the 
> switch each time it's not ideal, plus if you have a lot of enum cases then it 
> becomes increasingly burdensome to maintain when the values aren't set 
> alongside the cases themselves.
> 
> It's certainly one way to do it, but like I said .rawValue enables the size 
> to be set alongside each case, and pulled out much more cleanly, the only 
> problem is that you can't use tuples as a raw value, meanwhile conforming to 
> RawRepresentable can involve a lot more boiler plate overall (though once 
> done it works quite nicely), it's just overkill for any situation where a 
> tuple would do.
> 
> Again, if we had tuples for raw values we could easily do:
> 
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
> 
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }

Raw values are not a general solution, though, since enums with associated 
types can’t have them.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 struct or enum and think about 
> what you are trying to model; that will guide you towards the correct type(s) 
> to use.
> 
> You have only shown a handful of fixed size values, so I would suggest a 
> computed property in your case:
> 
> enum FixedSize {
>  case small
>  case medium
>  case large
> 
>  struct Size { let width : Int; let height: Int }
> 
>  var size : Size {
>switch self {
>case .small: return Size(width: 30, height: 30)
>// … etc
>}
>  }
> }
> 
> There is no need for these sizes to be stored at all. If you want them baked 
> in to your enum’s values, clearly you expect them to be specific values. It’s 
> more efficient to just drop the stored data altogether in this case; this 
> enum will get lowered in to single byte, which is more efficient to store and 
> transport.
> 
> Karl

Actually this is why I pointed to .rawValue as the solution; you're still using 
a lot of boiler-plate to implement the computed property via a switch; I don't 
know how well Swift optimises that, but if it actually runs the switch each 
time it's not ideal, plus if you have a lot of enum cases then it becomes 
increasingly burdensome to maintain when the values aren't set alongside the 
cases themselves.

It's certainly one way to do it, but like I said .rawValue enables the size to 
be set alongside each case, and pulled out much more cleanly, the only problem 
is that you can't use tuples as a raw value, meanwhile conforming to 
RawRepresentable can involve a lot more boiler plate overall (though once done 
it works quite nicely), it's just overkill for any situation where a tuple 
would do.

Again, if we had tuples for raw values we could easily do:

enum Format : (width:Int, height:Int) {
case small = (30, 30)
case medium = (60, 60)
case large = (120, 120)

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> 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 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 the concept, but this doesn’t seem as flexible as it could be, and 
>> could get ugly when mixing these defaults with enum associated values. How 
>> about dynamic properties instead? Something like:
>> 
>> enum RectSize {
>>  var height: Int { get }
>>  var width: Int { get }
>> 
>>  case small {
>>  height { return 30 }
>>  width { return 30 }
>>  }
>> 
>>  case medium {
>>  height { return 60 }
>>  width { return 60 }
>>  }
>> 
>>  case large {
>>  height { return 120 }
>>  width { return 120 }
>>  }
>> 
>>  case custom(width: Int, height: Int) {
>>  height { return height }
>>  width { return width }
>>  }
>> }
>> 
>> I'd be interested in expanding raw values to accommodate other types, but 
>> computed properties are already possible:
>> 
>> ```
>> enum RectSize {
>> case small, medium, large
>> 
>> var height: Int {
>> switch self {
>> case .small:
>> return 30
>> case .medium:
>> return 60
>> case .large:
>> return 120
>> }
>> }
>> 
>> var width: Int {
>> return height
>> }
>> } 
>> ```
>> 
>> There have been off-and-on proposals to change the syntax from what it is 
>> currently, but none have been deemed a significant enough advantage to merit 
>> a change--even before source-breaking changes in Swift 3 were over. Keeping 
>> in mind that sugar is the lowest priority for Swift 4 (and not in scope for 
>> the current phase), what's the advantage of your proposed syntax for 
>> computed properties over the existing one?
> 
> It’s *possible*, but the syntax is incredibly verbose, unwieldy, and ugly. 
> Imagine an enum with lots of cases and lots of properties—and before you say 
> this is contrived, this already currently happens quite a lot with error 
> enums (pardon the badly written error messages; this is only for example):
> 
> enum FileError: Error, LocalizedError {
> case notFound(url: URL)
> case accessDenied(url: URL)
> case incorrectFormat(url: URL)
> case ioError(url: URL)
> // ... imagine there are another 20 or so of these ...
> 
> // Now, implement LocalizedError:
> 
> var errorDescription: String? {
> switch self {
> case let .notFound(url: url):
> return "Could not access the file \(url.lastPathComponent) 
> because it could not be found."
> case let .accessDenied(url: url):
> return "Could not access the file \(url.lastPathComponent) 
> because access was denied."
> case let .incorrectFormat(url: url):
> return "Could not access the file \(url.lastPathComponent) 
> because it was not in the expected format."
> case let .ioError(url: url):
> return "Could not access the file \(url.lastPathComponent) 
> because an I/O error occurred."
> // ... etc ...
> }
> }
> 
> var failureReason: String? {
> switch self {
> case let .notFound(url: url):
> return "The file \(url.lastPathComponent) could not be found."
> case let .accessDenied(url: url):
> return "We do not have permission to view the file 
> \(url.lastPathComponent)"
> case let .incorrectFormat(url: url):
> return "The file \(url.lastPathComponent) was not in the expected 
> format."
> case let .ioError(url: url):
> return "An I/O error occurred while accessing the file 
> \(url.lastPathComponent)."
> // ... etc ...
> }
> }
> 
> var recoverySuggestion: String? {
> switch self {
> case .notFound:
> return "Please locate the correct file and try again."
> case .accessDenied:
> return "You can change the file's permissions using the Finder's 
> Get Info window."
> case .incorrectFormat:
> return "The file may have become corrupt."
> case .ioError:
> return "Dear Lord, the hard drive may be failing."
> // ... etc ...
> }
> }
> 
> var helpAnchor: String? {
> switch self {
> case .notFound:
> return "notFound"
> case .accessDenied:
> return "accessDenied"
> case 

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

[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 don’t all
> have a 1:1 equivalence relationship, so it’s possible for multiple
> enum cases to match the same raw struct. In that case, the order in
> which the compiler synthesises its checks is important, but it’s quite
> a hidden implementation detail that you wouldn’t be able to debug easily.
> It’s better to ask the user to implement the RawRep requirement
> themselves in those cases; it’s not a lot of work.

I'm aware of what is a basic idea behind RawRep. But it seems that I had a
wrong understanding of how rawValue's are managed. I was not aware of
the fact, that rawValue is created 'on demand' every time you use
.rawValue property on enum case. What it means, is that if you are
using a struct as a rawValue it is recreated from a string every
single time you are accessing rawValue. Not cool :)

Taking that into account I would consider changing the approach to
somethin more like
(http://swiftlang.ng.bluemix.net/#/repl/57febc248ef62b25bcea2a8a)
enum Format {

struct FormatStruct {
var width: Int = 0
var height: Int = 0

private init(width: Int, height: Int) {
print("GENERATE")
self.width = width
self.height = height
}

internal static let SMALL = FormatStruct(width: 30, height: 30)

internal static let MEDIUM = FormatStruct(width: 60, height: 60)

internal static let LARGE = FormatStruct(width: 120, height: 120)

}

case SMALL
case MEDIUM
case LARGE

var size: FormatStruct {
switch self {
case .SMALL:
return Format.FormatStruct.SMALL
case .MEDIUM:
return Format.FormatStruct.MEDIUM
case .LARGE:
return Format.FormatStruct.LARGE
}
}
var width: Int {
return size.width
}
var height: Int {
return size.height
}
}

I have to admit I was not expecting that. I thought, enum case
rawValues are managed similar to statics and only referred to by enum
cases. That was also a reason why I was convinced what 'storing'
values in properties could be achieved as a variation of rawValue.

Taking all of that into account I could agree that this proposal is more a
syntax update than a new language feature. Storing additional
properties would mean
1. store values as a part of enum case = extending required memory
(like it is done in case of associated values)
2. force compiler to generate a rawValue struct implementing
RawRepresentable protocol

> What I meant by that is that you want convenience accessors for extra stuff 
> you want to put in the enum’s payload (where the associated values are).
> I don’t think those values belong in the enum’s payload at all.

I never wanted to put anything in enum payload.

> What you propose looks dangerously close to the syntax for associated values, 
> IMO. A cleaner version might look like (strawman syntax):

No. It does not look event similar to what you described.

--
| Mateusz Malczak
+---



2016-10-12 21:20 GMT+02:00 Karl :
>
>> On 12 Oct 2016, at 18:44, Mateusz Malczak  wrote:
>>
>> 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, really does store an 
>>> instance of UIView or Error or Int along with it. The size of the value is 
>>> the maximum of those, plus a couple of bits > to record which case it is 
>>> and what the type of the payload is.
>>
>> This is something we already have - and example of enum with
>> associated values attached to enum cases. It has nothing to do with
>> this proposal.
>
> Yes, I know what it shows. I’m saying that your proposed syntax looks 
> dangerously close to what we already have (IMO), but means something entirely 
> different.
>
>>
>> The proposal is about being able to add stored immutable properties to enum 
>> type
>> (not to enum cases as it is in case of associated values). Just like you can
>> store properties in structs.
>>
>
> If the properties are:
>  - immutable, and
>  - tied to specific enum cases
>
> then there is no need for them to be stored. You are asking to produce a 
> hard-coded value based on the value of the enum - basically to wrap a switch 
> statement.
> We don’t need to store copies of numbers that are already baked in to your 
> source code.
>
>>> I think he wants convenience accessors for the associated values; the
>>> problem is that in his example, he shouldn’t even be 

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

[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, dynamic properties, etc. currently do.

I misspoke here; I meant to say that the *implementations* of the properties 
are implementation details. I.e. just as this:

struct MyStruct {
var foo: String {
return "Foo"
}

var bar: String {
return "Bar"
}
}

reduces to this:

internal struct MyStruct {

internal var foo: String { get }

internal var bar: String { get }
}

an enum declared like this:

enum MyEnum {
var desc: String { get }

case foo {
desc = "Foo"
}

case bar {
desc = "Bar"
}
}

would reduce to this:


enum MyEnum {
var desc: String { get }

case foo
case bar
}

The promise is that there will be a property named “desc” and that it will get 
you a string; that’s all that’s important to the interface.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 how many there are, which associated values they take, etc. That’s 
> important when writing a switch statement, for instance.

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, dynamic properties, etc. currently do.

> Secondly, related data is group together. All of the localised descriptions 
> are together, etc.

I guess we disagree on this. To me, it is much clearer to have the description 
of each case grouped together, rather than all the localized descriptions. It’s 
also a lot less verbose, to my mind easier to read, and it also makes it a lot 
quicker to create new cases or delete unnecessary ones.

> In real code, things like localised descriptions will likely come from a 
> common place - e.g. a localised string database.

The code shown was obviously simplified for the sake of example.

> Third: types. You never defined the type of any of these computed properties.

The type of the “url” property that I added was defined at the top of the 
example. The rest of the properties are defined in LocalizedError, where their 
types are given.

> It’s a fun example, but personally I don’t find it convincing. Several of 
> those values are closely related and could be grouped as a struct or tuple if 
> brevity is so important. Do you really need separate “failureReason” and 
> “recoverySuggestion” and “helpAnchor” properties?

Given that these properties are specified by the LocalizedError protocol, I’m 
gonna go with… yes.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 into (what seems to me to be) overly complex territory when
> many of us just want a nicer way to express cases likes these - not a whole
> new enum model that has to break everything.
>
> To be fair, the title is "Enums with stored properties” and the OP insists
> it is not just syntactic sugar.
>
> I think we all want better syntax for working with enums. They are groups
> of related values, so surely they have many common properties, but the
> barrier between enum cases in the language is sometimes far stronger than
> the barrier between them semantically.
>
> Maybe some kind of actual stored properties would be nice. Not like the
> “RectSize” example in this thread, where the values were all constants, but
> like the “FileError” example, where every case has a URL associated value.
> For example:
>
> enum Something {
> var timeTaken : TimeInterval
>
> case oneThing(Int)
> case anotherThing(Double)
> case yetAnother(Bool)
> }
>
> is equivalent to:
>
> enum Something {
> case oneThing(Int, TimeInterval)
> case anotherThing(Double, TimeInterval)
> case yetAnother(Bool, TimeInterval)
> }
>
> Since we know all payloads contain a TimeInterval and you didn’t specify a
> layout, we could lay them out in a predictable position for faster access.
> The compiler could probably do that anyway, even if you did specify an
> explicit tuple, but doesn’t today AFAIK. Maybe I’ll look at implementing
> that - we could maybe get away with it now, but it wouldn’t be worth the
> hassle once we have a stable ABI.


Yes, yes, let's talk about this in particular! I assume this offers
performance advantages over what's possible currently. Among the things I'd
like to find out: Was there a rationale for omitting this originally? Are
there any drawbacks in terms of performance of the simplest kinds of enums?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 of us just 
> want a nicer way to express cases likes these - not a whole new enum model 
> that has to break everything.

To be fair, the title is "Enums with stored properties” and the OP insists it 
is not just syntactic sugar.

I think we all want better syntax for working with enums. They are groups of 
related values, so surely they have many common properties, but the barrier 
between enum cases in the language is sometimes far stronger than the barrier 
between them semantically.

Maybe some kind of actual stored properties would be nice. Not like the 
“RectSize” example in this thread, where the values were all constants, but 
like the “FileError” example, where every case has a URL associated value. For 
example:

enum Something {
var timeTaken : TimeInterval

case oneThing(Int)
case anotherThing(Double)
case yetAnother(Bool)
}

is equivalent to:

enum Something {
case oneThing(Int, TimeInterval)
case anotherThing(Double, TimeInterval)
case yetAnother(Bool, TimeInterval)
}

Since we know all payloads contain a TimeInterval and you didn’t specify a 
layout, we could lay them out in a predictable position for faster access. The 
compiler could probably do that anyway, even if you did specify an explicit 
tuple, but doesn’t today AFAIK. Maybe I’ll look at implementing that - we could 
maybe get away with it now, but it wouldn’t be worth the hassle once we have a 
stable ABI.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 one obviously):
>> enum Size {
>>  let height: Int
>>  let width: Int
>>  case small {
>>  height = 30
>>  width = 30
>>  }
>>  case medium: {
>>  .height = 60
>>  .width = 60
>>  }
>>  case large = {
>>  let height = 120
>>  let width = 120
>>  }
>> }
> 
> I sort of prefer to have a protocol-like syntax for declaring the properties, 
> instead of let, because we’re doing something similar to what protocols do: 
> we’re promising that each of these things will provide the property, although 
> they might do it in different ways. This also avoids the connotation we have 
> with “let” that the property will be a constant, when in actuality it may be 
> dynamically computed and thus there is the possibility for it to be different 
> each time.

My expectation is that the stored properties *are* constants, maybe even 
compile-time, though I’m open to runtime-initialized options. The whole point 
of the stored properties (as far as I’m concerned) is that they vary between 
cases but are always the same for a particular case, similar to int- or 
string-backed enums. If there’s a truly variable property, it should not be 
part of whatever associated storage backs the cases.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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?

A complex reworking of enums is in scope, but no proposal that boils down
to a workaround to introduce new syntax would pass muster, I bet. Hence the
question, are there use cases not possible now that require ABI-breaking
changes to enum types? If not, we can safely pause the conversation.
On Wed, Oct 12, 2016 at 15:22 Sean Heber  wrote:

>
> > 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 { get }
> > >
> > > case notFound(url: URL) {
> > > errorDescription = "Could not access the file
> \(url.lastPathComponent) because it could not be found."
> > > failureReason = "The file \(url.lastPathComponent) could not
> be found."
> > > recoverySuggestion = "Please locate the correct file and try
> again."
> > > helpAnchor = "notFound"
> > > url = url
> > > }
> > >
> > > case accessDenied(url: URL) {
> > > errorDescription = "Could not access the file
> \(url.lastPathComponent) because access was denied."
> > > failureReason = "We do not have permission to view the file
> \(url.lastPathComponent)"
> > > recoverySuggestion = "You can change the file's permissions
> using the Finder's Get Info window."
> > > helpAnchor = "accessDenied"
> > > url = url
> > > }
> > >
> > > case incorrectFormat(url: URL) {
> > > errorDescription = "Could not access the file
> \(url.lastPathComponent) because it was not in the expected format."
> > > failureReason = "The file \(url.lastPathComponent) was not in
> the expected format."
> > > recoverySuggestion = "The file may have become corrupt."
> > > helpAnchor = "incorrectFormat"
> > > url = url
> > > }
> > >
> > > case ioError(url: URL) {
> > > errorDescription = "Could not access the file
> \(url.lastPathComponent) because an I/O error occurred."
> > > failureReason = "An I/O error occurred while accessing the
> file \(url.lastPathComponent)."
> > > recoverySuggestion = "Dear Lord, the hard drive may be
> failing."
> > > helpAnchor = "ioError"
> > > url = url
> > > }
> > >
> > > // ... etc ...
> > > }
> > >
> > > I don’t think it can be denied that the second is orders of magnitude
> easier to read and comprehend.
> > >
> > > Charles
> >
> > I’m 100% in favor of something approaching this syntax where the
> case-specific values are all grouped by the case and not the other way
> around.
> >
> > This particular suggestion has been made multiple times in the past. It
> is a proposal for sugar that did not converge on a consensus during either
> Swift 2 or 3 evolution. Since sugar is not in scope now and is still low
> priority for phase 2, let's focus on the potentially ABI-impacting issues
> here.
>
> I know - I’ve been here for some of those discussions and they always seem
> to get deferred with various excuses.
>
> 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 of us just
> want a nicer way to express cases likes these - not a whole new enum model
> that has to break everything.
>
> Such a “simple” change as this may not be in scope right now, but it seems
> as if the implication is that a far more complex breaking reworking of enum
> *is* somehow in scope and we should ignore simple syntactical improvements
> that might solve the same problems? That doesn’t make sense to me.
>
> l8r
> Sean
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 { get }
> >
> > case notFound(url: URL) {
> > errorDescription = "Could not access the file 
> > \(url.lastPathComponent) because it could not be found."
> > failureReason = "The file \(url.lastPathComponent) could not be 
> > found."
> > recoverySuggestion = "Please locate the correct file and try again."
> > helpAnchor = "notFound"
> > url = url
> > }
> >
> > case accessDenied(url: URL) {
> > errorDescription = "Could not access the file 
> > \(url.lastPathComponent) because access was denied."
> > failureReason = "We do not have permission to view the file 
> > \(url.lastPathComponent)"
> > recoverySuggestion = "You can change the file's permissions using 
> > the Finder's Get Info window."
> > helpAnchor = "accessDenied"
> > url = url
> > }
> >
> > case incorrectFormat(url: URL) {
> > errorDescription = "Could not access the file 
> > \(url.lastPathComponent) because it was not in the expected format."
> > failureReason = "The file \(url.lastPathComponent) was not in the 
> > expected format."
> > recoverySuggestion = "The file may have become corrupt."
> > helpAnchor = "incorrectFormat"
> > url = url
> > }
> >
> > case ioError(url: URL) {
> > errorDescription = "Could not access the file 
> > \(url.lastPathComponent) because an I/O error occurred."
> > failureReason = "An I/O error occurred while accessing the file 
> > \(url.lastPathComponent)."
> > recoverySuggestion = "Dear Lord, the hard drive may be failing."
> > helpAnchor = "ioError"
> > url = url
> > }
> >
> > // ... etc ...
> > }
> >
> > I don’t think it can be denied that the second is orders of magnitude 
> > easier to read and comprehend.
> >
> > Charles
> 
> I’m 100% in favor of something approaching this syntax where the 
> case-specific values are all grouped by the case and not the other way around.
> 
> This particular suggestion has been made multiple times in the past. It is a 
> proposal for sugar that did not converge on a consensus during either Swift 2 
> or 3 evolution. Since sugar is not in scope now and is still low priority for 
> phase 2, let's focus on the potentially ABI-impacting issues here.

I know - I’ve been here for some of those discussions and they always seem to 
get deferred with various excuses.

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 of us just want a 
nicer way to express cases likes these - not a whole new enum model that has to 
break everything.

Such a “simple” change as this may not be in scope right now, but it seems as 
if the implication is that a far more complex breaking reworking of enum *is* 
somehow in scope and we should ignore simple syntactical improvements that 
might solve the same problems? That doesn’t make sense to me.

l8r
Sean

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 = "Could not access the file
> \(url.lastPathComponent) because it could not be found."
> > failureReason = "The file \(url.lastPathComponent) could not be
> found."
> > recoverySuggestion = "Please locate the correct file and try
> again."
> > helpAnchor = "notFound"
> > url = url
> > }
> >
> > case accessDenied(url: URL) {
> > errorDescription = "Could not access the file
> \(url.lastPathComponent) because access was denied."
> > failureReason = "We do not have permission to view the file
> \(url.lastPathComponent)"
> > recoverySuggestion = "You can change the file's permissions
> using the Finder's Get Info window."
> > helpAnchor = "accessDenied"
> > url = url
> > }
> >
> > case incorrectFormat(url: URL) {
> > errorDescription = "Could not access the file
> \(url.lastPathComponent) because it was not in the expected format."
> > failureReason = "The file \(url.lastPathComponent) was not in
> the expected format."
> > recoverySuggestion = "The file may have become corrupt."
> > helpAnchor = "incorrectFormat"
> > url = url
> > }
> >
> > case ioError(url: URL) {
> > errorDescription = "Could not access the file
> \(url.lastPathComponent) because an I/O error occurred."
> > failureReason = "An I/O error occurred while accessing the file
> \(url.lastPathComponent)."
> > recoverySuggestion = "Dear Lord, the hard drive may be failing."
> > helpAnchor = "ioError"
> > url = url
> > }
> >
> > // ... etc ...
> > }
> >
> > I don’t think it can be denied that the second is orders of magnitude
> easier to read and comprehend.
> >
> > Charles
>
> I’m 100% in favor of something approaching this syntax where the
> case-specific values are all grouped by the case and not the other way
> around.
>

This particular suggestion has been made multiple times in the past. It is
a proposal for sugar that did not converge on a consensus during either
Swift 2 or 3 evolution. Since sugar is not in scope now and is still low
priority for phase 2, let's focus on the potentially ABI-impacting issues
here.

l8r
> Sean
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 when writing a switch statement, for instance.
Secondly, related data is group together. All of the localised descriptions are 
together, etc. In real code, things like localised descriptions will likely 
come from a common place - e.g. a localised string database.
Third: types. You never defined the type of any of these computed properties.

It’s a fun example, but personally I don’t find it convincing. Several of those 
values are closely related and could be grouped as a struct or tuple if brevity 
is so important. Do you really need separate “failureReason” and 
“recoverySuggestion” and “helpAnchor” properties? It seems to me like the first 
two are intended to always be displayed together, so you could reasonably group 
them. The helpAnchor seems to be some kind of reference - you could keep the 
separate accessor, but also use that same accessor to insert the value in to 
the aforementioned struct if you think it’s needed there, too (I would expect 
the compiler to be able to optimise the resulting switch statement away, given 
that it already knows the case of ’self’). You could also implement your 
LocalisedError accessor by forwarding to that same struct.

e.g:

struct ExtendedErrorInfo {
   var localisedDescription : String
   var failureReason : String
   var recoverySuggestion : String
   var anchor : String
}

enum FileError : Error {
   case notFound(URL)
   case accessDenied(URL)
   // ..etc

   var anchor : String {
  switch self {
 case .notFound(_):return “404”
 case .accessDenied(_): return “DENIED"
  }
   }

  var extendedInfo : ExtendedErrorInfo {
  switch self {
 case .notFound(let url):
return ExtendedErrorInfo(
  localizedDescription: “Couldn’t find file at 
\(url)”
  failureReason: "…”
  recoverySuggestion: "…”
  anchor: self.anchor)
 case .accessDenied(_):
return ExtendedErrorInfo(
  localizedDescription: “Access denied for file at 
\(url)”
  failureReason: "…”
  recoverySuggestion: "…”
  anchor: self.anchor)
  }
  }
}

extension FileInfo : LocalizedError {
var localizedDescription : String { 
return extendedInfo.localizedDescription 
}
}

That’s how I would do it if I cared about grouping that information together, 
in any case.

- Karl

> 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 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 the concept, but this doesn’t seem as flexible as it could be, and 
>> could get ugly when mixing these defaults with enum associated values. How 
>> about dynamic properties instead? Something like:
>> 
>> enum RectSize {
>>  var height: Int { get }
>>  var width: Int { get }
>> 
>>  case small {
>>  height { return 30 }
>>  width { return 30 }
>>  }
>> 
>>  case medium {
>>  height { return 60 }
>>  width { return 60 }
>>  }
>> 
>>  case large {
>>  height { return 120 }
>>  width { return 120 }
>>  }
>> 
>>  case custom(width: Int, height: Int) {
>>  height { return height }
>>  width { return width }
>>  }
>> }
>> 
>> I'd be interested in expanding raw values to accommodate other types, but 
>> computed properties are already possible:
>> 
>> ```
>> enum RectSize {
>> case small, medium, large
>> 
>> var height: Int {
>> switch self {
>> case .small:
>> return 30
>> case .medium:
>> return 60
>> case .large:
>> return 120
>> }
>> }
>> 
>> var width: Int {
>> return height
>> }
>> } 
>> ```
>> 
>> There have been off-and-on proposals to change the syntax from what it is 
>> currently, but none have been deemed a significant enough advantage to merit 
>> a change--even before 

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

[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, really does store an 
> instance of UIView or Error or Int along with it. The size of the value is 
> the maximum of those, plus a couple of bits > to record which case it is and 
> what the type of the payload is.

This is something we already have - and example of enum with
associated values attached to enum cases. It has nothing to do with
this proposal.

The proposal is about being able to add stored immutable properties to enum type
(not to enum cases as it is in case of associated values). Just like you can
store properties in structs.

> 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.

No, you are wrong, as I wrote its not even about associated values nor
about accessors.

>You can already use structs as raw types. You just have to implement the 
>RawRepresentable conformance yourself.

I know. And this has been also already discussed. Please see a
previously discussed example here:
https://swiftlang.ng.bluemix.net/#/repl/57fbf08a4f9bcf25fdd41634

And one more example with UIView stored in enum cases
http://swiftlang.ng.bluemix.net/#/repl/57fe67ad4bb9da26d5438387

The only problem here is an amount of boilerplate code you need to
create and limitations caused by using ExpressibleBy(*)Literal.

>I agree with Karl on this. There should be clarity here as to what's proposed.
>If it's a change to how enums are laid out in memory, then you'll need to
>show we're not sacrificing performance/size in the overwhelmingly more
>common use cases, and why the extra storage is useful in the first place;
>if it's syntactic sugar, that has already been proposed multiple times and
>really isn't in scope for this phase of Swift 4--nor does it really enable any 
>new use cases not possible now.

I agree when it comes to memory and performance, but at the same time
we do not have to focus on how it should be laid out in memory. This
is already solved. It is now possible to create enumeration type with
custom structs as a rawType (see examples above). Enumeration type with
stored properties could be handled in exactly the same way. Taking
this into account I don't see any danger in terms of memory or
performance hits.

In my opinion it's also not a syntactic sugar.

Lets get back to the previously discussed example

We are discussing here a enumeration type defined as
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)
}
where
var size: RectSize = .small
size.height == 30 // true
size.rawValue // Error:  RectSizes has no property `rawValue`.
size.height = 40 // Error:  `height` is immutable
print(size.height) // output: 30


There are at least two ways of this could be done.

First solution would be to implement this as a new feature next to
already existing two (enum with associated values, enum with
rawValue). I don't have any detailed implementation in head.

Second approach would be to use struct as a rawValue. This feature is
already available.

struct UnderlyingRectSizeEnumStruct {
var width: Int
var height: Int
init(width: width, height: height) {
self.width = width
self.height = height
}
}

enum RectSize: UnderlyingRectSizeEnumStruct
{
   case small(width: 30, height: 30)
   case medium(width: 60, height: 60)
   case large(width: 120, height: 120)
}


I hope this explains what was the initial idea behind this proposal.

--
| Mateusz Malczak
+---

2016-10-12 17:07 GMT+02:00 Karl :
> 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 computed property. There is nothing to be stored 
> here. Meanwhile, something like:
>
> enum Something {
>case oneThing(UIView)
>case anotherThing(Error)
>case yetAnotherThing(Int)
> }
>
> …which is dangerously similar to Braeden’s example, really does store an 
> instance of UIView or Error or Int along with it. The size of the value is 
> the maximum of those, plus a couple of bits to record which case it is and 
> what the type of the payload is.
>
> Confusing those things just because you don’t like writing switch statements 
> would be bad, IMO. It’s not that much code, and once you’ve done a few of 
> them you can make it quite compact. If you have a boatload of associated 
> values, wrap them in a struct.
> Some more convenient 

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

[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 return the size. You can 
either do that every time you need a size from the enum, or you can extend the 
enum and make it a computed property.

I do sometimes wonder why we don’t have better accessors. We have the “if case 
let” thing, but that’s horrible. On the rare occasion where it’s appropriate, 
it always takes me 4 or 5 attempts to get the incantation correct (single 
equals!):

if case .anotherThing(let theError) = myValue {
print(“oh, no! an error! \(theError)”)
}

Urf.

- Karl
> On 12 Oct 2016, at 17:12, Xiaodi Wu  wrote:
> 
> 
> 
> On Wed, Oct 12, 2016 at 10:07 AM, Karl via swift-evolution 
> > 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 a PITA, I get it, I go through it all the time, too; but really this is 
> the very definition of a computed property. There is nothing to be stored 
> here. Meanwhile, something like:
> 
> enum Something {
>case oneThing(UIView)
>case anotherThing(Error)
>case yetAnotherThing(Int)
> }
> 
> …which is dangerously similar to Braeden’s example, really does store an 
> instance of UIView or Error or Int along with it. The size of the value is 
> the maximum of those, plus a couple of bits to record which case it is and 
> what the type of the payload is.
> 
> Confusing those things just because you don’t like writing switch statements 
> would be bad, IMO. It’s not that much code, and once you’ve done a few of 
> them you can make it quite compact. If you have a boatload of associated 
> values, wrap them in a struct.
> Some more convenient generated accessors for the associated data might be 
> nice, but that’s been proposed and discussed to death. Others who have 
> followed the lists more closely can maybe tell you why we don’t have an 
> accepted proposal for it.
> 
> I agree with Karl on this. There should be clarity here as to what's 
> proposed. If it's a change to how enums are laid out in memory, then you'll 
> need to show we're not sacrificing performance/size in the overwhelmingly 
> more common use cases, and why the extra storage is useful in the first 
> place; if it's syntactic sugar, that has already been proposed multiple times 
> and really isn't in scope for this phase of Swift 4--nor does it really 
> enable any new use cases not possible now.
>  
> - Karl
> 
> > On 12 Oct 2016, at 13:52, Rien  wrote:
> >
> > 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’ instead of 
> > hidden in a tree of multiple ‘var’s.
> > While I was sceptical about this proposal, Braeden’s example makes it a +1.
> >
> > Rien.
> >
> > Btw: I made the almost identical suggestion you did ;-)
> >
> >
> >> On 12 Oct 2016, at 13:31, Karl  >> > 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 struct or enum and think 
> >> about what you are trying to model; that will guide you towards the 
> >> correct type(s) to use.
> >>
> >> You have only shown a handful of fixed size values, so I would suggest a 
> >> computed property in your case:
> >>
> >> enum FixedSize {
> >> case small
> >> case medium
> >> case large
> >>
> >> struct Size { let width : Int; let height: Int }
> >>
> >> var size : Size {
> >>   switch self {
> >>   case .small: return Size(width: 30, height: 30)
> >>   // … etc
> >>   }
> >> }
> >> }
> >>
> >> There is no need for these sizes to be stored at all. If you want them 
> >> baked in to your enum’s values, clearly you expect them to be specific 
> >> values. It’s more efficient to just drop the stored data altogether in 
> >> this case; this enum will get lowered in to single byte, which is more 
> >> efficient to store and transport.
> >>
> >> Karl
> >>
> >>> On 12 Oct 2016, at 13:15, Mateusz Malczak via swift-evolution 
> >>> > wrote:
> >>>
>  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” 

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

[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 a PITA, I get it, I go through it all the time, too; but really this
> is the very definition of a computed property. There is nothing to be
> stored here. Meanwhile, something like:
>
> enum Something {
>case oneThing(UIView)
>case anotherThing(Error)
>case yetAnotherThing(Int)
> }
>
> …which is dangerously similar to Braeden’s example, really does store an
> instance of UIView or Error or Int along with it. The size of the value is
> the maximum of those, plus a couple of bits to record which case it is and
> what the type of the payload is.
>
> Confusing those things just because you don’t like writing switch
> statements would be bad, IMO. It’s not that much code, and once you’ve done
> a few of them you can make it quite compact. If you have a boatload of
> associated values, wrap them in a struct.
> Some more convenient generated accessors for the associated data might be
> nice, but that’s been proposed and discussed to death. Others who have
> followed the lists more closely can maybe tell you why we don’t have an
> accepted proposal for it.
>

I agree with Karl on this. There should be clarity here as to what's
proposed. If it's a change to how enums are laid out in memory, then you'll
need to show we're not sacrificing performance/size in the overwhelmingly
more common use cases, and why the extra storage is useful in the first
place; if it's syntactic sugar, that has already been proposed multiple
times and really isn't in scope for this phase of Swift 4--nor does it
really enable any new use cases not possible now.


> - Karl
>
> > On 12 Oct 2016, at 13:52, Rien  wrote:
> >
> > 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’ instead
> of hidden in a tree of multiple ‘var’s.
> > While I was sceptical about this proposal, Braeden’s example makes it a
> +1.
> >
> > Rien.
> >
> > Btw: I made the almost identical suggestion you did ;-)
> >
> >
> >> On 12 Oct 2016, at 13:31, Karl  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 struct or enum
> and think about what you are trying to model; that will guide you towards
> the correct type(s) to use.
> >>
> >> You have only shown a handful of fixed size values, so I would suggest
> a computed property in your case:
> >>
> >> enum FixedSize {
> >> case small
> >> case medium
> >> case large
> >>
> >> struct Size { let width : Int; let height: Int }
> >>
> >> var size : Size {
> >>   switch self {
> >>   case .small: return Size(width: 30, height: 30)
> >>   // … etc
> >>   }
> >> }
> >> }
> >>
> >> There is no need for these sizes to be stored at all. If you want them
> baked in to your enum’s values, clearly you expect them to be specific
> values. It’s more efficient to just drop the stored data altogether in this
> case; this enum will get lowered in to single byte, which is more efficient
> to store and transport.
> >>
> >> Karl
> >>
> >>> On 12 Oct 2016, at 13:15, Mateusz Malczak via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
>  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 Braeden example explains the
> >>> whole idea of that proposal.
> >>>
> >>> --
> >>> | Mateusz Malczak
> >>>
> >>>
> >>> 2016-10-12 8:42 GMT+02:00 Rien :
>  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 <
> swift-evolution@swift.org> 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.
> > --
> > | Mateusz Malczak
> > +---
> > | mate...@malczak.info
> > | http://malczak.info
> >
> >
> > 2016-10-11 23:42 GMT+02:00 Braeden Profile :

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

[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 computed property. There is nothing to be stored here. 
Meanwhile, something like:

enum Something {
   case oneThing(UIView)
   case anotherThing(Error)
   case yetAnotherThing(Int)
}

…which is dangerously similar to Braeden’s example, really does store an 
instance of UIView or Error or Int along with it. The size of the value is the 
maximum of those, plus a couple of bits to record which case it is and what the 
type of the payload is.

Confusing those things just because you don’t like writing switch statements 
would be bad, IMO. It’s not that much code, and once you’ve done a few of them 
you can make it quite compact. If you have a boatload of associated values, 
wrap them in a struct.
Some more convenient generated accessors for the associated data might be nice, 
but that’s been proposed and discussed to death. Others who have followed the 
lists more closely can maybe tell you why we don’t have an accepted proposal 
for it.

- Karl

> On 12 Oct 2016, at 13:52, Rien  wrote:
> 
> 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’ instead of 
> hidden in a tree of multiple ‘var’s.
> While I was sceptical about this proposal, Braeden’s example makes it a +1.
> 
> Rien.
> 
> Btw: I made the almost identical suggestion you did ;-)
> 
> 
>> On 12 Oct 2016, at 13:31, Karl  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 struct or enum and think about 
>> what you are trying to model; that will guide you towards the correct 
>> type(s) to use.
>> 
>> You have only shown a handful of fixed size values, so I would suggest a 
>> computed property in your case:
>> 
>> enum FixedSize {
>> case small
>> case medium
>> case large
>> 
>> struct Size { let width : Int; let height: Int }
>> 
>> var size : Size {
>>   switch self {
>>   case .small: return Size(width: 30, height: 30)
>>   // … etc
>>   }
>> }
>> }
>> 
>> There is no need for these sizes to be stored at all. If you want them baked 
>> in to your enum’s values, clearly you expect them to be specific values. 
>> It’s more efficient to just drop the stored data altogether in this case; 
>> this enum will get lowered in to single byte, which is more efficient to 
>> store and transport.
>> 
>> Karl
>> 
>>> On 12 Oct 2016, at 13:15, Mateusz Malczak via swift-evolution 
>>>  wrote:
>>> 
 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 Braeden example explains the
>>> whole idea of that proposal.
>>> 
>>> --
>>> | Mateusz Malczak
>>> 
>>> 
>>> 2016-10-12 8:42 GMT+02:00 Rien :
 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 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 :
>> 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 of a
>> finite number of options, possibly with data attached.  In proposal 1, we
>> want some sort of syntax where this…
>> 
>> 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)
>> }
>> 
>> …is syntactically 

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

[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 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’ instead of 
> hidden in a tree of multiple ‘var’s.
> While I was sceptical about this proposal, Braeden’s example makes it a +1.
> 
> Rien.
> 
> Btw: I made the almost identical suggestion you did ;-)
> 
> 
>> On 12 Oct 2016, at 13:31, Karl  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 struct or enum and think about 
>> what you are trying to model; that will guide you towards the correct 
>> type(s) to use.
>> 
>> You have only shown a handful of fixed size values, so I would suggest a 
>> computed property in your case:
>> 
>> enum FixedSize {
>> case small
>> case medium
>> case large
>> 
>> struct Size { let width : Int; let height: Int }
>> 
>> var size : Size {
>>   switch self {
>>   case .small: return Size(width: 30, height: 30)
>>   // … etc
>>   }
>> }
>> }
>> 
>> There is no need for these sizes to be stored at all. If you want them baked 
>> in to your enum’s values, clearly you expect them to be specific values. 
>> It’s more efficient to just drop the stored data altogether in this case; 
>> this enum will get lowered in to single byte, which is more efficient to 
>> store and transport.
>> 
>> Karl
>> 
 On 12 Oct 2016, at 13:15, Mateusz Malczak via swift-evolution 
  wrote:
 
 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 Braeden example explains the
>>> whole idea of that proposal.
>>> 
>>> --
>>> | Mateusz Malczak
>>> 
>>> 
>>> 2016-10-12 8:42 GMT+02:00 Rien :
 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 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 :
>> 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 of a
>> finite number of options, possibly with data attached.  In proposal 1, we
>> want some sort of syntax where this…
>> 
>> 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)
>> }
>> 
>> …is syntactically just like writing this…
>> 
>> enum RectSize
>> {
>> case small
>> case medium
>> case large
>> var height:Int
>> {
>>   switch self
>>   {
>>  case .small: return 30
>>  case .medium: return 60
>>  case .large: return 90
>>   }
>> }
>> let width:Int
>> {
>>   switch self
>>   {
>>  case .small: return 30
>>  case .medium: return 60
>>  case .large: return 90
>>   }
>> }
>> }
>> 
>> …right?  That way, you can write this:
>> 
>> var size: RectSize = .small
>> size.height == 30 // true
>> size.rawValue // Error:  RectSizes has no property `rawValue`.
>> size.height = 40 // Error:  `height` is immutable
>> size = .medium
>> 
>> I think we were also (separately) proposing to extend `rawValue` to take 
>> all
>> kinds of statically known values, like structs or tuples.  Doing that 
>> would
>> accomplish much of the same thing.
>> 
>> Someone fact-check me here!  I really 

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

[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’ instead of hidden 
in a tree of multiple ‘var’s.
While I was sceptical about this proposal, Braeden’s example makes it a +1.

Rien.

Btw: I made the almost identical suggestion you did ;-)


> On 12 Oct 2016, at 13:31, Karl  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 struct or enum and think about 
> what you are trying to model; that will guide you towards the correct type(s) 
> to use.
> 
> You have only shown a handful of fixed size values, so I would suggest a 
> computed property in your case:
> 
> enum FixedSize {
>  case small
>  case medium
>  case large
> 
>  struct Size { let width : Int; let height: Int }
> 
>  var size : Size {
>switch self {
>case .small: return Size(width: 30, height: 30)
>// … etc
>}
>  }
> }
> 
> There is no need for these sizes to be stored at all. If you want them baked 
> in to your enum’s values, clearly you expect them to be specific values. It’s 
> more efficient to just drop the stored data altogether in this case; this 
> enum will get lowered in to single byte, which is more efficient to store and 
> transport.
> 
> Karl
> 
>> On 12 Oct 2016, at 13:15, Mateusz Malczak via swift-evolution 
>>  wrote:
>> 
>>> 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 Braeden example explains the
>> whole idea of that proposal.
>> 
>> --
>> | Mateusz Malczak
>> 
>> 
>> 2016-10-12 8:42 GMT+02:00 Rien :
>>> 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 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 :
> 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 of a
> finite number of options, possibly with data attached.  In proposal 1, we
> want some sort of syntax where this…
> 
> 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)
> }
> 
> …is syntactically just like writing this…
> 
> enum RectSize
> {
> case small
> case medium
> case large
> var height:Int
> {
>switch self
>{
>   case .small: return 30
>   case .medium: return 60
>   case .large: return 90
>}
> }
> let width:Int
> {
>switch self
>{
>   case .small: return 30
>   case .medium: return 60
>   case .large: return 90
>}
> }
> }
> 
> …right?  That way, you can write this:
> 
> var size: RectSize = .small
> size.height == 30 // true
> size.rawValue // Error:  RectSizes has no property `rawValue`.
> size.height = 40 // Error:  `height` is immutable
> size = .medium
> 
> I think we were also (separately) proposing to extend `rawValue` to take 
> all
> kinds of statically known values, like structs or tuples.  Doing that 
> would
> accomplish much of the same thing.
> 
> Someone fact-check me here!  I really do think something like this would 
> be
> a good idea, if we could get the right syntax.
> 
> On Oct 11, 2016, at 7:06 AM, Mateusz Malczak via swift-evolution
>  wrote:
> 
> Hi,
> I think we are here discussing two different aspects of introducing
> this new feature - code syntax and underlying implementation.
> In terms 

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

[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 only reason the type needs to be a string/integer 
literal in that case is so that we can check uniqueness and solve the most 
common case. If you write your own implementation, you can handle the more 
nuanced stuff there.

I don’t think there are any restrictions at all on RawRepresentable.RawType 
(not even Comparable). It can be anything you like.

Karl

> On 12 Oct 2016, at 13:22, Mateusz Malczak via swift-evolution 
>  wrote:
> 
> 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 MyEnum: MyStruct
> {
> case myStructCase1(width: 30, height: 30)
> case myStructCase2(width: 60, height: 60)
> ...
> }
> 
> 2. calling .rawVaue should not be required in such case to access
> stored properties
> 
> let e = MyEnum.myStructCase1
> let width = e.width // instead of e.rawValue.width
> 
> Immutability of all properties in enum struct type is already
> implemented in Swift.
> At the same time .rawValue stays as it is for primitive types.
> 
> --
> | Mateusz Malczak
> +---
> 
> 
> 2016-10-12 13:02 GMT+02:00 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 a type to a tuple loses the computed properties and methods of the
>> type.
>> The types must be equatable I suppose.
>> 
>> The current enum rawValues are just indexes or keys which the compiler can
>> autogenerate (like it does for enums without a raw type).
>> Of course the raw values can be used in some smart way, like for sorting or
>> grouping cases, but this can all be done with general types - and better at
>> that.
>> 
>> So basically you have a struct type and an enum which is just a set of
>> static lets of the struct type.
>> struct MyStruct {}
>> enum MyEnum: MyStruct
>> {
>> case myStruct1
>> case myStruct2
>> ...
>> }
>> 
>> MyStruct need not be created specifically for the enum; it might be useful
>> on its own.
>> MyEnum can have additional computed properties and methods which are needed
>> for the enumerated values only.
>> 
>> The cases can be accessed like MyStruct instances. No need for .rawValue
>> except in the case of primitive types. Even there there is room for sugar
>> (if a variable is already known to be of type Int we can assign an enum:Int
>> case to it with implied .rawValue).
>> 
>> Jan E.
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 MyEnum: MyStruct
{
case myStructCase1(width: 30, height: 30)
case myStructCase2(width: 60, height: 60)
...
}

2. calling .rawVaue should not be required in such case to access
stored properties

let e = MyEnum.myStructCase1
let width = e.width // instead of e.rawValue.width

Immutability of all properties in enum struct type is already
implemented in Swift.
At the same time .rawValue stays as it is for primitive types.

--
| Mateusz Malczak
+---


2016-10-12 13:02 GMT+02:00 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 a type to a tuple loses the computed properties and methods of the
> type.
> The types must be equatable I suppose.
>
> The current enum rawValues are just indexes or keys which the compiler can
> autogenerate (like it does for enums without a raw type).
> Of course the raw values can be used in some smart way, like for sorting or
> grouping cases, but this can all be done with general types - and better at
> that.
>
> So basically you have a struct type and an enum which is just a set of
> static lets of the struct type.
> struct MyStruct {}
> enum MyEnum: MyStruct
> {
> case myStruct1
> case myStruct2
> ...
> }
>
> MyStruct need not be created specifically for the enum; it might be useful
> on its own.
> MyEnum can have additional computed properties and methods which are needed
> for the enumerated values only.
>
> The cases can be accessed like MyStruct instances. No need for .rawValue
> except in the case of primitive types. Even there there is room for sugar
> (if a variable is already known to be of type Int we can assign an enum:Int
> case to it with implied .rawValue).
>
> Jan E.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 Braeden example explains the
whole idea of that proposal.

--
| Mateusz Malczak


2016-10-12 8:42 GMT+02:00 Rien :
> 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 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 :
>>> 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 of a
>>> finite number of options, possibly with data attached.  In proposal 1, we
>>> want some sort of syntax where this…
>>>
>>> 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)
>>> }
>>>
>>> …is syntactically just like writing this…
>>>
>>> enum RectSize
>>> {
>>>   case small
>>>   case medium
>>>   case large
>>>   var height:Int
>>>   {
>>>  switch self
>>>  {
>>> case .small: return 30
>>> case .medium: return 60
>>> case .large: return 90
>>>  }
>>>   }
>>>   let width:Int
>>>   {
>>>  switch self
>>>  {
>>> case .small: return 30
>>> case .medium: return 60
>>> case .large: return 90
>>>  }
>>>   }
>>> }
>>>
>>> …right?  That way, you can write this:
>>>
>>> var size: RectSize = .small
>>> size.height == 30 // true
>>> size.rawValue // Error:  RectSizes has no property `rawValue`.
>>> size.height = 40 // Error:  `height` is immutable
>>> size = .medium
>>>
>>> I think we were also (separately) proposing to extend `rawValue` to take all
>>> kinds of statically known values, like structs or tuples.  Doing that would
>>> accomplish much of the same thing.
>>>
>>> Someone fact-check me here!  I really do think something like this would be
>>> a good idea, if we could get the right syntax.
>>>
>>> On Oct 11, 2016, at 7:06 AM, Mateusz Malczak via swift-evolution
>>>  wrote:
>>>
>>> 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 during compilation internal struct is created, as
>>> well as any required property getters. This way you could get a
>>> variation of rawValue implementation, at least from theoretical point
>>> of view :D
>>>
>>> --
>>> | Mateusz Malczak
>>> +---
>>> | mate...@malczak.info
>>> | http://malczak.info
>>>
>>>
>>> 2016-10-10 23:42 GMT+02:00 Haravikk :
>>>
>>>
>>> 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 something
>>> like this:
>>>
>>>
>>> We have three different possible solution
>>> 1. stored properties defined as part of enumeration type
>>> enum RectSizes: MyRect
>>> {
>>>  let height:Int
>>>  let width:Int
>>>  case Small(width: 30, height: 30)
>>>  case Medium(width: 60, height: 60)
>>>  case Large(width: 120, height: 120)
>>> }
>>>
>>> 2. struct as rawValue
>>> struct MyRect
>>> {
>>>  var height:Int
>>>  var width:Int
>>>  var area:Int {return height:Int*width}
>>> }
>>>
>>> enum RectSizes: MyRect
>>> {
>>>  case Small(30,30)
>>>  case Medium(60,60)
>>>  case Large(120,120)
>>> }
>>>
>>> 3. tuples as rawValue
>>> enum Format : (width:Int, height:Int) {
>>>  case small(30, 30)
>>>  case medium(60, 60)
>>>  case large(120, 120)
>>>
>>>  var width:Int { return self.rawValue.width }
>>>  var height:Int { return self.rawValue.height }
>>> }
>>>
>>> Solutions 2 and 3 are quire similar, to get value of a stored property
>>> we need to use rawValue or define value getters. In addition in
>>> solution 2 we define an 

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

[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 a type to a tuple loses the computed properties and methods of the 
type.
The types must be equatable I suppose.

The current enum rawValues are just indexes or keys which the compiler can 
autogenerate (like it does for enums without a raw type). 
Of course the raw values can be used in some smart way, like for sorting or 
grouping cases, but this can all be done with general types - and better at 
that.

So basically you have a struct type and an enum which is just a set of static 
lets of the struct type.
struct MyStruct {}
enum MyEnum: MyStruct
{
case myStruct1
case myStruct2
...
}

MyStruct need not be created specifically for the enum; it might be useful on 
its own.
MyEnum can have additional computed properties and methods which are needed for 
the enumerated values only.

The cases can be accessed like MyStruct instances. No need for .rawValue except 
in the case of primitive types. Even there there is room for sugar (if a 
variable is already known to be of type Int we can assign an enum:Int case to 
it with implied .rawValue).

Jan E.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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 :
>> 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 of a
>> finite number of options, possibly with data attached.  In proposal 1, we
>> want some sort of syntax where this…
>> 
>> 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)
>> }
>> 
>> …is syntactically just like writing this…
>> 
>> enum RectSize
>> {
>>   case small
>>   case medium
>>   case large
>>   var height:Int
>>   {
>>  switch self
>>  {
>> case .small: return 30
>> case .medium: return 60
>> case .large: return 90
>>  }
>>   }
>>   let width:Int
>>   {
>>  switch self
>>  {
>> case .small: return 30
>> case .medium: return 60
>> case .large: return 90
>>  }
>>   }
>> }
>> 
>> …right?  That way, you can write this:
>> 
>> var size: RectSize = .small
>> size.height == 30 // true
>> size.rawValue // Error:  RectSizes has no property `rawValue`.
>> size.height = 40 // Error:  `height` is immutable
>> size = .medium
>> 
>> I think we were also (separately) proposing to extend `rawValue` to take all
>> kinds of statically known values, like structs or tuples.  Doing that would
>> accomplish much of the same thing.
>> 
>> Someone fact-check me here!  I really do think something like this would be
>> a good idea, if we could get the right syntax.
>> 
>> On Oct 11, 2016, at 7:06 AM, Mateusz Malczak via swift-evolution
>>  wrote:
>> 
>> 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 during compilation internal struct is created, as
>> well as any required property getters. This way you could get a
>> variation of rawValue implementation, at least from theoretical point
>> of view :D
>> 
>> --
>> | Mateusz Malczak
>> +---
>> | mate...@malczak.info
>> | http://malczak.info
>> 
>> 
>> 2016-10-10 23:42 GMT+02:00 Haravikk :
>> 
>> 
>> 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 something
>> like this:
>> 
>> 
>> We have three different possible solution
>> 1. stored properties defined as part of enumeration type
>> enum RectSizes: MyRect
>> {
>>  let height:Int
>>  let width:Int
>>  case Small(width: 30, height: 30)
>>  case Medium(width: 60, height: 60)
>>  case Large(width: 120, height: 120)
>> }
>> 
>> 2. struct as rawValue
>> struct MyRect
>> {
>>  var height:Int
>>  var width:Int
>>  var area:Int {return height:Int*width}
>> }
>> 
>> enum RectSizes: MyRect
>> {
>>  case Small(30,30)
>>  case Medium(60,60)
>>  case Large(120,120)
>> }
>> 
>> 3. tuples as rawValue
>> enum Format : (width:Int, height:Int) {
>>  case small(30, 30)
>>  case medium(60, 60)
>>  case large(120, 120)
>> 
>>  var width:Int { return self.rawValue.width }
>>  var height:Int { return self.rawValue.height }
>> }
>> 
>> Solutions 2 and 3 are quire similar, to get value of a stored property
>> we need to use rawValue or define value getters. In addition in
>> solution 2 we define an additional data type just to be used as an
>> enumeration type rawValue type. In my opinion, first approach would be
>> a best solution, type definition is clear and self-explanatory because
>> it is similar to how enums/classes are defined.
>> 
>> 
>> --
>> | Mateusz Malczak
>> 
>> 
>> Actually I'd say your option 2 here is more similar to option 1 (you seem to
>> be using a struct to define the stored properties instead). The issue here
>> is that storing properties conflicts with what you're actually doing, which
>> is storing case-specific values, which 

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

[Xiaodi Wu via swift-evolution]

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: 30, height: 30)
>case medium(width: 60, height: 60)
>case large(width: 120, height: 120)
> }
>
>
> I like the concept, but this doesn’t seem as flexible as it could be, and
> could get ugly when mixing these defaults with enum associated values. How
> about dynamic properties instead? Something like:
>
> enum RectSize {
> var height: Int { get }
> var width: Int { get }
>
> case small {
> height { return 30 }
> width { return 30 }
> }
>
> case medium {
> height { return 60 }
> width { return 60 }
> }
>
> case large {
> height { return 120 }
> width { return 120 }
> }
>
> case custom(width: Int, height: Int) {
> height { return height }
> width { return width }
> }
> }
>

I'd be interested in expanding raw values to accommodate other types, but
computed properties are already possible:

```
enum RectSize {
case small, medium, large

var height: Int {
switch self {
case .small:
return 30
case .medium:
return 60
case .large:
return 120
}
}

var width: Int {
return height
}
}
```

There have been off-and-on proposals to change the syntax from what it is
currently, but none have been deemed a significant enough advantage to
merit a change--even before source-breaking changes in Swift 3 were over.
Keeping in mind that sugar is the lowest priority for Swift 4 (and not in
scope for the current phase), what's the advantage of your proposed syntax
for computed properties over the existing one?


(syntax not exact; this is pseudocode, modify the syntax as appropriate)
>
> This would keep the property implementations separate from the associated
> values, and would also allow for the computed properties to do more complex
> calculations if necessary.
>
> Charles
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 the concept, but this doesn’t seem as flexible as it could be, and could 
get ugly when mixing these defaults with enum associated values. How about 
dynamic properties instead? Something like:

enum RectSize {
var height: Int { get }
var width: Int { get }

case small {
height { return 30 }
width { return 30 }
}

case medium {
height { return 60 }
width { return 60 }
}

case large {
height { return 120 }
width { return 120 }
}

case custom(width: Int, height: Int) {
height { return height }
width { return width }
}
}

(syntax not exact; this is pseudocode, modify the syntax as appropriate)

This would keep the property implementations separate from the associated 
values, and would also allow for the computed properties to do more complex 
calculations if necessary.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

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 :
> 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 of a
> finite number of options, possibly with data attached.  In proposal 1, we
> want some sort of syntax where this…
>
> 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)
> }
>
> …is syntactically just like writing this…
>
> enum RectSize
> {
>case small
>case medium
>case large
>var height:Int
>{
>   switch self
>   {
>  case .small: return 30
>  case .medium: return 60
>  case .large: return 90
>   }
>}
>let width:Int
>{
>   switch self
>   {
>  case .small: return 30
>  case .medium: return 60
>  case .large: return 90
>   }
>}
> }
>
> …right?  That way, you can write this:
>
> var size: RectSize = .small
> size.height == 30 // true
> size.rawValue // Error:  RectSizes has no property `rawValue`.
> size.height = 40 // Error:  `height` is immutable
> size = .medium
>
> I think we were also (separately) proposing to extend `rawValue` to take all
> kinds of statically known values, like structs or tuples.  Doing that would
> accomplish much of the same thing.
>
> Someone fact-check me here!  I really do think something like this would be
> a good idea, if we could get the right syntax.
>
> On Oct 11, 2016, at 7:06 AM, Mateusz Malczak via swift-evolution
>  wrote:
>
> 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 during compilation internal struct is created, as
> well as any required property getters. This way you could get a
> variation of rawValue implementation, at least from theoretical point
> of view :D
>
> --
> | Mateusz Malczak
> +---
> | mate...@malczak.info
> | http://malczak.info
>
>
> 2016-10-10 23:42 GMT+02:00 Haravikk :
>
>
> 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 something
> like this:
>
>
> We have three different possible solution
> 1. stored properties defined as part of enumeration type
> enum RectSizes: MyRect
> {
>   let height:Int
>   let width:Int
>   case Small(width: 30, height: 30)
>   case Medium(width: 60, height: 60)
>   case Large(width: 120, height: 120)
> }
>
> 2. struct as rawValue
> struct MyRect
> {
>   var height:Int
>   var width:Int
>   var area:Int {return height:Int*width}
> }
>
> enum RectSizes: MyRect
> {
>   case Small(30,30)
>   case Medium(60,60)
>   case Large(120,120)
> }
>
> 3. tuples as rawValue
> enum Format : (width:Int, height:Int) {
>   case small(30, 30)
>   case medium(60, 60)
>   case large(120, 120)
>
>   var width:Int { return self.rawValue.width }
>   var height:Int { return self.rawValue.height }
> }
>
> Solutions 2 and 3 are quire similar, to get value of a stored property
> we need to use rawValue or define value getters. In addition in
> solution 2 we define an additional data type just to be used as an
> enumeration type rawValue type. In my opinion, first approach would be
> a best solution, type definition is clear and self-explanatory because
> it is similar to how enums/classes are defined.
>
>
> --
> | Mateusz Malczak
>
>
> Actually I'd say your option 2 here is more similar to option 1 (you seem to
> be using a struct to define the stored properties instead). The issue here
> is that storing properties conflicts with what you're actually doing, which
> is storing case-specific values, which is what rawValue already does, it's
> just too limited for your current use-case (multiple values).
>
> The complete solution would be to introduce the concept of tuples as
> literals (even though they can't currently conform to types); this would
> make it a lot easier to support the use of any type as a fixed value for
> each case (not just tuples). For example, say we introduced as new protocol:
>
> protocol 

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

[Braeden Profile via swift-evolution]

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 of a finite 
number of options, possibly with data attached.  In proposal 1, we want some 
sort of syntax where this…

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)
}

…is syntactically just like writing this…

enum RectSize
{
   case small
   case medium
   case large
   var height:Int
   {
  switch self
  {
 case .small: return 30
 case .medium: return 60
 case .large: return 90
  }
   }
   let width:Int
   {
  switch self
  {
 case .small: return 30
 case .medium: return 60
 case .large: return 90
  }
   }
}

…right?  That way, you can write this:

var size: RectSize = .small
size.height == 30 // true
size.rawValue // Error:  RectSizes has no property `rawValue`.
size.height = 40 // Error:  `height` is immutable
size = .medium

I think we were also (separately) proposing to extend `rawValue` to take all 
kinds of statically known values, like structs or tuples.  Doing that would 
accomplish much of the same thing.

Someone fact-check me here!  I really do think something like this would be a 
good idea, if we could get the right syntax.

> On Oct 11, 2016, at 7:06 AM, Mateusz Malczak via swift-evolution 
>  wrote:
> 
> 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 during compilation internal struct is created, as
> well as any required property getters. This way you could get a
> variation of rawValue implementation, at least from theoretical point
> of view :D
> 
> --
> | Mateusz Malczak
> +---
> | mate...@malczak.info
> | http://malczak.info
> 
> 
> 2016-10-10 23:42 GMT+02:00 Haravikk :
>> 
>> 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 something
>> like this:
>> 
>> 
>> We have three different possible solution
>> 1. stored properties defined as part of enumeration type
>> enum RectSizes: MyRect
>> {
>>   let height:Int
>>   let width:Int
>>   case Small(width: 30, height: 30)
>>   case Medium(width: 60, height: 60)
>>   case Large(width: 120, height: 120)
>> }
>> 
>> 2. struct as rawValue
>> struct MyRect
>> {
>>   var height:Int
>>   var width:Int
>>   var area:Int {return height:Int*width}
>> }
>> 
>> enum RectSizes: MyRect
>> {
>>   case Small(30,30)
>>   case Medium(60,60)
>>   case Large(120,120)
>> }
>> 
>> 3. tuples as rawValue
>> enum Format : (width:Int, height:Int) {
>>   case small(30, 30)
>>   case medium(60, 60)
>>   case large(120, 120)
>> 
>>   var width:Int { return self.rawValue.width }
>>   var height:Int { return self.rawValue.height }
>> }
>> 
>> Solutions 2 and 3 are quire similar, to get value of a stored property
>> we need to use rawValue or define value getters. In addition in
>> solution 2 we define an additional data type just to be used as an
>> enumeration type rawValue type. In my opinion, first approach would be
>> a best solution, type definition is clear and self-explanatory because
>> it is similar to how enums/classes are defined.
>> 
>> 
>> --
>> | Mateusz Malczak
>> 
>> 
>> Actually I'd say your option 2 here is more similar to option 1 (you seem to
>> be using a struct to define the stored properties instead). The issue here
>> is that storing properties conflicts with what you're actually doing, which
>> is storing case-specific values, which is what rawValue already does, it's
>> just too limited for your current use-case (multiple values).
>> 
>> The complete solution would be to introduce the concept of tuples as
>> literals (even though they can't currently conform to types); this would
>> make it a lot easier to support the use of any type as a fixed value for
>> each case (not just tuples). For example, say we introduced as new protocol:
>> 
>> protocol ExpressableByTuple {
>> associatedtype TupleType // somehow force this to be a tuple or
>> ExpressableByType type
>> init(tupleLiteral:TupleType)
>> }
>> 
>> With a bit of magic all tuples could conform to this protocol with
>> themselves as the literal type, allowing us to use them as enum raw values;
>> likewise this could then be used to more 

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

[Mateusz Malczak via swift-evolution]

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 during compilation internal struct is created, as
well as any required property getters. This way you could get a
variation of rawValue implementation, at least from theoretical point
of view :D

--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info


2016-10-10 23:42 GMT+02:00 Haravikk :
>
> 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 something
> like this:
>
>
> We have three different possible solution
> 1. stored properties defined as part of enumeration type
> enum RectSizes: MyRect
> {
>let height:Int
>let width:Int
>case Small(width: 30, height: 30)
>case Medium(width: 60, height: 60)
>case Large(width: 120, height: 120)
> }
>
> 2. struct as rawValue
> struct MyRect
> {
>var height:Int
>var width:Int
>var area:Int {return height:Int*width}
> }
>
> enum RectSizes: MyRect
> {
>case Small(30,30)
>case Medium(60,60)
>case Large(120,120)
> }
>
> 3. tuples as rawValue
> enum Format : (width:Int, height:Int) {
>case small(30, 30)
>case medium(60, 60)
>case large(120, 120)
>
>var width:Int { return self.rawValue.width }
>var height:Int { return self.rawValue.height }
> }
>
> Solutions 2 and 3 are quire similar, to get value of a stored property
> we need to use rawValue or define value getters. In addition in
> solution 2 we define an additional data type just to be used as an
> enumeration type rawValue type. In my opinion, first approach would be
> a best solution, type definition is clear and self-explanatory because
> it is similar to how enums/classes are defined.
>
>
> --
> | Mateusz Malczak
>
>
> Actually I'd say your option 2 here is more similar to option 1 (you seem to
> be using a struct to define the stored properties instead). The issue here
> is that storing properties conflicts with what you're actually doing, which
> is storing case-specific values, which is what rawValue already does, it's
> just too limited for your current use-case (multiple values).
>
> The complete solution would be to introduce the concept of tuples as
> literals (even though they can't currently conform to types); this would
> make it a lot easier to support the use of any type as a fixed value for
> each case (not just tuples). For example, say we introduced as new protocol:
>
> protocol ExpressableByTuple {
> associatedtype TupleType // somehow force this to be a tuple or
> ExpressableByType type
> init(tupleLiteral:TupleType)
> }
>
> With a bit of magic all tuples could conform to this protocol with
> themselves as the literal type, allowing us to use them as enum raw values;
> likewise this could then be used to more easily enable any custom
> struct/class for storage in enum cases, as instead of supporting their
> constructors directly we can just support construction via a tuple literal.
>
>
> My other reason I don't favour option 1, while it looks a bit prettier, is
> that it's a bit confusing; enums have two types of stored properties, ones
> that can be changed (and inspected) which is what you get when you declare
> case small(Int, Int) for example, these are stored as part of the enum
> itself (so in that example it's 17-bytes on a 64-bit system). However
> rawValues are more like constants/static values, and don't increase the size
> of the type, and I just feel that this is the right way to do what you're
> proposing.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 something
>> like this:
> 
> We have three different possible solution
> 1. stored properties defined as part of enumeration type
> enum RectSizes: MyRect
> {
>let height:Int
>let width:Int
>case Small(width: 30, height: 30)
>case Medium(width: 60, height: 60)
>case Large(width: 120, height: 120)
> }
> 
> 2. struct as rawValue
> struct MyRect
> {
>var height:Int
>var width:Int
>var area:Int {return height:Int*width}
> }
> 
> enum RectSizes: MyRect
> {
>case Small(30,30)
>case Medium(60,60)
>case Large(120,120)
> }
> 
> 3. tuples as rawValue
> enum Format : (width:Int, height:Int) {
>case small(30, 30)
>case medium(60, 60)
>case large(120, 120)
> 
>var width:Int { return self.rawValue.width }
>var height:Int { return self.rawValue.height }
> }
> 
> Solutions 2 and 3 are quire similar, to get value of a stored property
> we need to use rawValue or define value getters. In addition in
> solution 2 we define an additional data type just to be used as an
> enumeration type rawValue type. In my opinion, first approach would be
> a best solution, type definition is clear and self-explanatory because
> it is similar to how enums/classes are defined.
> 
> 
> --
> | Mateusz Malczak

Actually I'd say your option 2 here is more similar to option 1 (you seem to be 
using a struct to define the stored properties instead). The issue here is that 
storing properties conflicts with what you're actually doing, which is storing 
case-specific values, which is what rawValue already does, it's just too 
limited for your current use-case (multiple values).

The complete solution would be to introduce the concept of tuples as literals 
(even though they can't currently conform to types); this would make it a lot 
easier to support the use of any type as a fixed value for each case (not just 
tuples). For example, say we introduced as new protocol:

protocol ExpressableByTuple {
associatedtype TupleType // somehow force this to be a tuple or 
ExpressableByType type
init(tupleLiteral:TupleType)
}

With a bit of magic all tuples could conform to this protocol with themselves 
as the literal type, allowing us to use them as enum raw values; likewise this 
could then be used to more easily enable any custom struct/class for storage in 
enum cases, as instead of supporting their constructors directly we can just 
support construction via a tuple literal.


My other reason I don't favour option 1, while it looks a bit prettier, is that 
it's a bit confusing; enums have two types of stored properties, ones that can 
be changed (and inspected) which is what you get when you declare case 
small(Int, Int) for example, these are stored as part of the enum itself (so in 
that example it's 17-bytes on a 64-bit system). However rawValues are more like 
constants/static values, and don't increase the size of the type, and I just 
feel that this is the right way to do what you're proposing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

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 :
>
> 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 }
>var height:Int { return self.rawValue }
> }
>
>
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
>
> --
> | Mateusz Malczak
>
>
> 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:
>
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
>
> This currently isn't supported as tuples aren't treated as a literal type,
> even when composed of literal types.
>
> Since enum values can be anything that is representable as literal (except
> arrays, apparently, which I tried but don't seem to work), you can implement
> this with a lot of boiler-plate like so:
>
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable
> {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
>
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue:
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue:
> unicodeScalarLiteral)! }
>
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy:
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width ==
> rhs.width) && (lhs.height == rhs.height) }
>
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
> Not at all pretty, but it works (and I believe the string parsing should
> optimise away in practice).
>
> Anyway, my point is that the best solution to the problem you're trying to
> solve would be to expand the enum raw value support to include tuples.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Marinus van der Lugt via swift-evolution]

> 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 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 width/height are the same. Im talking
>> here about more general use case when you can assign different values
>> of different types to an enum case. Please refer to the example code:
>> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8 
>> 
>> 
>> --
>> | Mateusz Malczak
> 
> 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:
> 
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
> 
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
> 
> This currently isn't supported as tuples aren't treated as a literal type, 
> even when composed of literal types.
> 

Nice, that ties in well with a recent post here about deriving enums from other 
types:

struct Size {
   let width: Double
   let height: Double
}

enum Format: Size {
   case small = Size(width: 30, height: 30)
   case medium = Size(width: 60, height: 60)
}

let format = Format.small
let size = format.width

I’d like that a lot!


> Since enum values can be anything that is representable as literal (except 
> arrays, apparently, which I tried but don't seem to work), you can implement 
> this with a lot of boiler-plate like so:
> 
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
> 
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue: 
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue: 
> unicodeScalarLiteral)! }
> 
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy: 
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width == 
> rhs.width) && (lhs.height == rhs.height) }
> 
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
> 
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
> 
> Not at all pretty, but it works (and I believe the string parsing should 
> optimise away in practice).
> 
> Anyway, my point is that the best solution to the problem you're trying to 
> solve would be to expand the enum raw value support to include tuples.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

> 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 properties defined as part of enumeration type
enum RectSizes: MyRect
{
let height:Int
let width:Int
case Small(width: 30, height: 30)
case Medium(width: 60, height: 60)
case Large(width: 120, height: 120)
}

2. struct as rawValue
struct MyRect
{
var height:Int
var width:Int
var area:Int {return height:Int*width}
}

enum RectSizes: MyRect
{
case Small(30,30)
case Medium(60,60)
case Large(120,120)
}

3. tuples as rawValue
enum Format : (width:Int, height:Int) {
case small(30, 30)
case medium(60, 60)
case large(120, 120)

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

Solutions 2 and 3 are quire similar, to get value of a stored property
we need to use rawValue or define value getters. In addition in
solution 2 we define an additional data type just to be used as an
enumeration type rawValue type. In my opinion, first approach would be
a best solution, type definition is clear and self-explanatory because
it is similar to how enums/classes are defined.


--
| Mateusz Malczak
+---


2016-10-10 21:18 GMT+02:00 Haravikk :
>
> 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 }
>var height:Int { return self.rawValue }
> }
>
>
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
>
> --
> | Mateusz Malczak
>
>
> 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:
>
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
>
> This currently isn't supported as tuples aren't treated as a literal type,
> even when composed of literal types.
>
> Since enum values can be anything that is representable as literal (except
> arrays, apparently, which I tried but don't seem to work), you can implement
> this with a lot of boiler-plate like so:
>
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable
> {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
>
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue:
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue:
> unicodeScalarLiteral)! }
>
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy:
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width ==
> rhs.width) && (lhs.height == rhs.height) }
>
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
> Not at all pretty, but it works (and I believe the string parsing should
> optimise away in practice).
>
> Anyway, my point is that the best solution to the problem you're trying to
> solve would be to expand the enum raw value support to include tuples.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 }
>>var height:Int { return self.rawValue }
>> }
> 
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
> 
> --
> | Mateusz Malczak

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:

enum Format : (width:Int, height:Int) {
case small = (30, 30)
case medium = (60, 60)
case large = (120, 120)

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

This currently isn't supported as tuples aren't treated as a literal type, even 
when composed of literal types.

Since enum values can be anything that is representable as literal (except 
arrays, apparently, which I tried but don't seem to work), you can implement 
this with a lot of boiler-plate like so:

struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable {
let width:Int, height:Int
init(width:Int, height:Int) { self.width = width; self.height = height }

init(extendedGraphemeClusterLiteral:String) { self.init(rawValue: 
extendedGraphemeClusterLiteral)! }
init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
init(unicodeScalarLiteral:String) { self.init(rawValue: 
unicodeScalarLiteral)! }

var rawValue:String { return "\(self.width),\(self.height)" }
init?(rawValue:String) { let parts = rawValue.components(separatedBy: ","); 
self.width = Int(parts[0])!; self.height = Int(parts[1])! }
}
func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width == 
rhs.width) && (lhs.height == rhs.height) }

enum Format : Dimensions {
case small = "30,30"
case medium = "60,60"
case large = "120,120"

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

Not at all pretty, but it works (and I believe the string parsing should 
optimise away in practice).

Anyway, my point is that the best solution to the problem you're trying to 
solve would be to expand the enum raw value support to include tuples.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

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 properties without using rawValue
--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info


2016-10-10 20:54 GMT+02:00 J.E. Schotsman via swift-evolution
:
>
> 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
>
>
> Wouldn’t it be more natural to allow structs as raw values?
>
> For example
>
> struct MyRect
> {
> var height:Int
> var width:Int
> var area:Int {return height:Int*width}
> }
>
> enum RectSizes: MyRect
> {
> case Small(30,30)
> case Medium(60,60)
> case Large(120,120)
> }
>
> let smallArea = RectSizes.Small.rawValue.area
>
> Jan E.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

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 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
> 
> Wouldn’t it be more natural to allow structs as raw values?
> 
> For example
> 
> struct MyRect
>   {
>   var height:Int
>   var width:Int
>   var area:Int {return height:Int*width}
>   }
> 
> enum RectSizes: MyRect
>   {
>   case Small(30,30)
>   case Medium(60,60)
>   case Large(120,120)
>   }
> 
> let smallArea = RectSizes.Small.rawValue.area
> 
> Jan E.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

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 proper way, as a set 
of compile-time-constant data accessed in an easier way than having to use the 
ugly but currently necessary hack of `switch value { case .x: return 1; case 
.y: return 2; … }`.

> On Oct 10, 2016, at 11:52 AM, Kevin Nattinger  wrote:
> 
> 
>> 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 data, and data takes 
>> far more useful forms than just bitfields
> 
> I’m not sure where you got “bitfields” from, perhaps I was unclear. I think 
> enums should be a set of cases, each case having its distinct and constant 
> set of data with the same structure. If one entity needs data of different, 
> dynamic structure and value at runtime, that is essentially the definition of 
> a union.
> 
>> - similarly when it does have that form it fits precisely into the form of 
>> an enum with no cases?  Why artificially separate the two concepts when 
>> they’re clearly one and the same?
>> 
>> ~Robert Widmann
>> 
>>> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>>> > wrote:
>>> 
>>> 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 
 > wrote:
 
 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 have only a single attribute.
 
 -Kenny
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[J.E. Schotsman via swift-evolution]

> 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

Wouldn’t it be more natural to allow structs as raw values?

For example

struct MyRect
{
var height:Int
var width:Int
var area:Int {return height:Int*width}
}

enum RectSizes: MyRect
{
case Small(30,30)
case Medium(60,60)
case Large(120,120)
}

let smallArea = RectSizes.Small.rawValue.area

Jan E.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

> 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 data, and data takes far 
> more useful forms than just bitfields

I’m not sure where you got “bitfields” from, perhaps I was unclear. I think 
enums should be a set of cases, each case having its distinct and constant set 
of data with the same structure. If one entity needs data of different, dynamic 
structure and value at runtime, that is essentially the definition of a union.

> - similarly when it does have that form it fits precisely into the form of an 
> enum with no cases?  Why artificially separate the two concepts when they’re 
> clearly one and the same?
> 
> ~Robert Widmann
> 
>> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>> > wrote:
>> 
>> 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 
>>> > wrote:
>>> 
>>> 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 have only a single attribute.
>>> 
>>> -Kenny
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

> 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
> instance.rawValue // would be rawInstance1
> instance.value // would be storeInstance1

I think its a bit too enigmatic, and stored properties should be
explicitly defined as part of enumeration type. Just like in case of
Java enums example.

enum Format: FormatStruct {
let width: Double
let height: Double

case SMALL(width: 30, height: 30)
case MEDIUM(width: 60, height: 60)
case LARGE(width: 120, height: 120)

}

The way I see enumeration type with stored properties is something
different that enums with rawValue.

2016-10-10 20:33 GMT+02:00 Adrian Zubarev via swift-evolution
:
> 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 = (rawInstance2, storeInstance2)
> case c = rawInstance3, storeInstance3 // or not tuple like?
> }
>
> let instance = Enum.a
> instance.rawValue // would be rawInstance1
> instance.value // would be storeInstance1
>
> StoreType could be anything (even another two type enum).
>
> It would be interesting to read what you thing of that simple model. Plus
> should .value be mutable? Maybe we could communicate that somehow.
>
> Or we could simply allow tuples on enums where the first item is always the
> RawType of the enum?!
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 10. Oktober 2016 um 19:32:20, Kenny Leung via swift-evolution
> (swift-evolution@swift.org) schrieb:
>
> 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 have only a single attribute.
>
> -Kenny
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 = (rawInstance2, storeInstance2)
case c = rawInstance3, storeInstance3 // or not tuple like?
}

let instance = Enum.a
instance.rawValue // would be rawInstance1
instance.value // would be storeInstance1
StoreType could be anything (even another two type enum).

It would be interesting to read what you thing of that simple model. Plus 
should .value be mutable? Maybe we could communicate that somehow.

Or we could simply allow tuples on enums where the first item is always the 
RawType of the enum?!



-- 
Adrian Zubarev
Sent with Airmail

Am 10. Oktober 2016 um 19:32:20, Kenny Leung via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 have only a single attribute.

-Kenny


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

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 have that form it 
fits precisely into the form of an enum with no cases?  Why artificially 
separate the two concepts when they’re clearly one and the same?

~Robert Widmann

> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> 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 
>>  wrote:
>> 
>> 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 have only a single attribute.
>> 
>> -Kenny
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

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 
>  wrote:
> 
> 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 have only a single attribute.
> 
> -Kenny
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kenny Leung via swift-evolution]

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 have only a single attribute.

-Kenny


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

> 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 example : https://swiftlang.ng.bluemix.net/#/repl/57fb99c54f9bcf25fdd415f3

> 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 {
>case SMALL: return Size(width: 100, height: 100)
>case MEDIUM: …
>….
>  }
> }
> }
>
> let format = Format.SMALL
> let width = format.size.width
>
> format.size.width = 50 // error, immutable
>
>
>
>> On 10 Oct 2016, at 14:35, Jay Abbott via swift-evolution 
>>  wrote:
>>
>> 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
>> 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 instead I would like to make it possible to store a
>> const values in enumeration cases. So going back to my example once
>> again:
>>
>> Lest define an enumeration type `Format` with 3 possible cases. Each
>> case will be able to carry over some additional information - in this
>> case a pair of numbers (but in fact Any? should be possible)
>>
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>>
>> I'm not sure about 'var' clause in that example as it causes all the 
>> confusion.
>>
>> I can access additional info stored in enum case, but it cannot be
>> modified. Format.SMALL doesn't change, as well as non of its
>> properties.
>>
>> // allowed usage
>> let format = Format.SMALL
>> let width = format.width // this would be equal to 30 (const value
>> assigned to 'width' property on enum case .SMALL)
>>
>> // not allowed usage
>> let format = Format.SMALL
>> format.width = 40 // error, stored values are immutable and can not be 
>> modified
>>
>> We get all advantages of enumeration type, and, assuming all cases are
>> describing the same possible state, we can store some extra
>> information in each case. This can be called a third enumeration type
>> feature, right next to associated values and rawType.
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
>> > 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
>> >
>> > Is that right?
>> >
>> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>> >  wrote:
>> >>
>> >> 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 :)
>> >>
>> >> --
>> >> | Mateusz Malczak
>> >>
>> >>
>> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> >> :
>> >> > 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 to the
>> >> > varying
>> >> > elements.
>> >> >
>> >> > Now, I end up creating a secondary struct T and doing case a(T,
>> >> > whatever),
>> >> > b(T, whatever), c(T, whatever), etc. where the same associated structure
>> >> > is
>> >> > every case, *or* I end up putting the enum into a struct which means the
>> >> > guiding semantics are the struct and not the enumeration. Both
>> >> > approaches
>> >> > are ugly.
>> >> >
>> >> > -- E
>> >> >
>> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > 

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

[Mateusz Malczak via swift-evolution]

> 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 width/height are the same. Im talking
here about more general use case when you can assign different values
of different types to an enum case. Please refer to the example code:
https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8

--
| Mateusz Malczak


2016-10-10 15:31 GMT+02:00 Haravikk :
>
> 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 type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
>
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
>
> enum Format {
>case SMALL(30, 30)
>case MEDIUM(60, 60)
>case LARGE(120, 120)
>var width: Double
>var height: Double
>init(width: Double, height: Double) {
>self.width = width
>self.height = height
>}
> }
>
> I'm not sure about 'var' clause in that example as it causes all the
> confusion.
>
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
>
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
>
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be
> modified
>
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
>
> --
> | Mateusz Malczak
>
>
> 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 }
> }
>
>
> Granted this becomes more complex if you want to specify widths and heights
> that do not match, as you can't currently specify a tuple as the raw value,
> but if you could then that seems like it would be a better solution to this
> problem surely?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
> 
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
> 
> enum Format {
>case SMALL(30, 30)
>case MEDIUM(60, 60)
>case LARGE(120, 120)
>var width: Double
>var height: Double
>init(width: Double, height: Double) {
>self.width = width
>self.height = height
>}
> }
> 
> I'm not sure about 'var' clause in that example as it causes all the 
> confusion.
> 
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
> 
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
> 
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be 
> modified
> 
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
> 
> --
> | Mateusz Malczak

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 }
}

Granted this becomes more complex if you want to specify widths and heights 
that do not match, as you can't currently specify a tuple as the raw value, but 
if you could then that seems like it would be a better solution to this problem 
surely?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

> 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 enum cases.
http://swiftlang.ng.bluemix.net/#/repl/57fb8e3e4f9bcf25fdd415cd

What I would like to achieve is (more or less)
http://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8

regards
--
| Mateusz Malczak


2016-10-10 14:35 GMT+02:00 Jay Abbott :
> 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
>> 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 instead I would like to make it possible to store a
>> const values in enumeration cases. So going back to my example once
>> again:
>>
>> Lest define an enumeration type `Format` with 3 possible cases. Each
>> case will be able to carry over some additional information - in this
>> case a pair of numbers (but in fact Any? should be possible)
>>
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>>
>> I'm not sure about 'var' clause in that example as it causes all the
>> confusion.
>>
>> I can access additional info stored in enum case, but it cannot be
>> modified. Format.SMALL doesn't change, as well as non of its
>> properties.
>>
>> // allowed usage
>> let format = Format.SMALL
>> let width = format.width // this would be equal to 30 (const value
>> assigned to 'width' property on enum case .SMALL)
>>
>> // not allowed usage
>> let format = Format.SMALL
>> format.width = 40 // error, stored values are immutable and can not be
>> modified
>>
>> We get all advantages of enumeration type, and, assuming all cases are
>> describing the same possible state, we can store some extra
>> information in each case. This can be called a third enumeration type
>> feature, right next to associated values and rawType.
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
>> > 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
>> >
>> > Is that right?
>> >
>> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>> >  wrote:
>> >>
>> >> 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 :)
>> >>
>> >> --
>> >> | Mateusz Malczak
>> >>
>> >>
>> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> >> :
>> >> > 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 to the
>> >> > varying
>> >> > elements.
>> >> >
>> >> > Now, I end up creating a secondary struct T and doing case a(T,
>> >> > whatever),
>> >> > b(T, whatever), c(T, whatever), etc. where the same associated
>> >> > structure
>> >> > is
>> >> > every case, *or* I end up putting the enum into a struct which means
>> >> > the
>> >> > guiding semantics are the struct and not the enumeration. Both
>> >> > approaches
>> >> > are ugly.
>> >> >
>> >> > -- E
>> >> >
>> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > Mateusz,
>> >> >
>> >> > 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. What could you do with this special enum - what would the
>> >> > code
>> >> > that
>> >> > uses it look like?
>> >> >
>> >> >
>> >> >
>> >> > On Sun, 9 Oct 2016 at 04:56 

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

[Rien via swift-evolution]

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 {
   case SMALL: return Size(width: 100, height: 100)
   case MEDIUM: …
   ….
 }
}
}

let format = Format.SMALL
let width = format.size.width

format.size.width = 50 // error, immutable



> On 10 Oct 2016, at 14:35, Jay Abbott via swift-evolution 
>  wrote:
> 
> 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
> 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 instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
> 
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
> 
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> 
> I'm not sure about 'var' clause in that example as it causes all the 
> confusion.
> 
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
> 
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
> 
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be 
> modified
> 
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
> 
> --
> | Mateusz Malczak
> 
> 
> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
> > 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
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> >  wrote:
> >>
> >> 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 :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> :
> >> > 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 to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> >  wrote:
> >> >
> >> > Mateusz,
> >> >
> >> > 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. What could you do with this special enum - what would the code
> >> > that
> >> > uses it look like?
> >> >
> >> >
> >> >
> >> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >> >  wrote:
> >> >>
> >> >> I’ve 

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

[Jay Abbott via swift-evolution]

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
> 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 instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
>
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
>
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
>
> I'm not sure about 'var' clause in that example as it causes all the
> confusion.
>
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
>
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
>
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be
> modified
>
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
> > 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
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> >  wrote:
> >>
> >> 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 :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> :
> >> > 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 to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated
> structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means
> the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> >  wrote:
> >> >
> >> > Mateusz,
> >> >
> >> > 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. What could you do with this special enum - what would the code
> >> > that
> >> > uses it look like?
> >> >
> >> >
> >> >
> >> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >> >  wrote:
> >> >>
> >> >> I’ve started doing this to try and mimic “Smart Constructors” in
> >> >> Haskell
> >> >> and I think it works quite well.
> >> >>
> >> >> struct Format {
> >> >>   enum FormatBacking {
> >> >> case SMALL(Int, Int)
> >> >> case MEDIUM(Int, Int)
> >> >> case LARGE(Int, Int)
> >> >>   }
> >> >
> >> >
> >> > ___
> >> > swift-evolution mailing list
> >> > swift-evolution@swift.org
> >> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >> >
> >> >
> >> >
> >> > ___
> >> > swift-evolution mailing list
> >> > swift-evolution@swift.org
> >> > 

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

[Mateusz Malczak via swift-evolution]

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 instead I would like to make it possible to store a
const values in enumeration cases. So going back to my example once
again:

Lest define an enumeration type `Format` with 3 possible cases. Each
case will be able to carry over some additional information - in this
case a pair of numbers (but in fact Any? should be possible)

enum Format {
case SMALL(30, 30)
case MEDIUM(60, 60)
case LARGE(120, 120)
var width: Double
var height: Double
init(width: Double, height: Double) {
self.width = width
self.height = height
}
}

I'm not sure about 'var' clause in that example as it causes all the confusion.

I can access additional info stored in enum case, but it cannot be
modified. Format.SMALL doesn't change, as well as non of its
properties.

// allowed usage
let format = Format.SMALL
let width = format.width // this would be equal to 30 (const value
assigned to 'width' property on enum case .SMALL)

// not allowed usage
let format = Format.SMALL
format.width = 40 // error, stored values are immutable and can not be modified

We get all advantages of enumeration type, and, assuming all cases are
describing the same possible state, we can store some extra
information in each case. This can be called a third enumeration type
feature, right next to associated values and rawType.

--
| Mateusz Malczak


2016-10-10 13:40 GMT+02:00 Jay Abbott :
> 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
>
> Is that right?
>
> On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>  wrote:
>>
>> 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 :)
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> :
>> > 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 to the
>> > varying
>> > elements.
>> >
>> > Now, I end up creating a secondary struct T and doing case a(T,
>> > whatever),
>> > b(T, whatever), c(T, whatever), etc. where the same associated structure
>> > is
>> > every case, *or* I end up putting the enum into a struct which means the
>> > guiding semantics are the struct and not the enumeration. Both
>> > approaches
>> > are ugly.
>> >
>> > -- E
>> >
>> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >  wrote:
>> >
>> > Mateusz,
>> >
>> > 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. What could you do with this special enum - what would the code
>> > that
>> > uses it look like?
>> >
>> >
>> >
>> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>> >  wrote:
>> >>
>> >> I’ve started doing this to try and mimic “Smart Constructors” in
>> >> Haskell
>> >> and I think it works quite well.
>> >>
>> >> struct Format {
>> >>   enum FormatBacking {
>> >> case SMALL(Int, Int)
>> >> case MEDIUM(Int, Int)
>> >> case LARGE(Int, Int)
>> >>   }
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

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

Is that right?

On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 :)
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> :
> > 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 to the
> varying
> > elements.
> >
> > Now, I end up creating a secondary struct T and doing case a(T,
> whatever),
> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> is
> > every case, *or* I end up putting the enum into a struct which means the
> > guiding semantics are the struct and not the enumeration. Both approaches
> > are ugly.
> >
> > -- E
> >
> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >  wrote:
> >
> > Mateusz,
> >
> > 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. What could you do with this special enum - what would the code
> that
> > uses it look like?
> >
> >
> >
> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >  wrote:
> >>
> >> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
> >> and I think it works quite well.
> >>
> >> struct Format {
> >>   enum FormatBacking {
> >> case SMALL(Int, Int)
> >> case MEDIUM(Int, Int)
> >> case LARGE(Int, Int)
> >>   }
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

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 :)

--
| Mateusz Malczak


2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
:
> 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 to the varying
> elements.
>
> Now, I end up creating a secondary struct T and doing case a(T, whatever),
> b(T, whatever), c(T, whatever), etc. where the same associated structure is
> every case, *or* I end up putting the enum into a struct which means the
> guiding semantics are the struct and not the enumeration. Both approaches
> are ugly.
>
> -- E
>
> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>  wrote:
>
> Mateusz,
>
> 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. What could you do with this special enum - what would the code that
> uses it look like?
>
>
>
> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>  wrote:
>>
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
>> and I think it works quite well.
>>
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

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 it from that perspective you will see that
having stored properties is an extension to rawType usage.

> Java’s constants are convenient but they are an oddly structural feature in a 
> particularly nominal language
> which makes it not scale particularly cleanly.

why do  you think such a feature would not scale cleanly? can you
elaborate a bit more on that sentence please

--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info


2016-10-09 5:55 GMT+02:00 Robert Widmann :
> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and
> I think it works quite well.
>
> struct Format {
>   enum FormatBacking {
> case SMALL(Int, Int)
> case MEDIUM(Int, Int)
> case LARGE(Int, Int)
>   }
>   private let unFormat : FormatBacking
>
>   static var Small : Format {
> return Format(unFormat: .SMALL(30, 30))
>   }
>
>   static var Medium : Format {
> return Format(unFormat: .MEDIUM(60, 60))
>   }
>
>   static var Large : Format {
> return Format(unFormat: .LARGE(120, 120))
>   }
>
>   var width : Int {
> switch self.unFormat {
> case let .SMALL(w, _):
>   return w
> case let .MEDIUM(w, _):
>   return w
> case let .LARGE(w, _):
>   return w
> }
>   }
>
>   var height : Int {
> switch self.unFormat {
> case let .SMALL(_, h):
>   return h
> case let .MEDIUM(_, h):
>   return h
> case let .LARGE(_, h):
>   return h
> }
>   }
> }
>
> Yeah, you’re still subject the switching stuff you mentioned before, but I
> don’t think this is a whole lot of code.  Java’s constants are convenient
> but they are an oddly structural feature in a particularly nominal language
> which makes it not scale particularly cleanly.
>
> ~Robert Widmann
>
> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution
>  wrote:
>
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
>
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>
> This is precisely what a struct is for, why would you want to be able to do
> this with enums instead?
>
> Hi all,
> I would like to know you opinion on one feature I feel would be a real 'nice
> to have' extension to currently available enumeration type. Which is an
> enumeration type with stored properties. It is sometimes useful to store
> some extra informations along with enumeration cases. Idea here is to add
> possibility to define an enumeration type with stored, immutable,
> properties, defined at compile time for all cases. In opposition to
> currently available associated values, stored properties should be constant
> values stored as a part of enumeration case. Proposed feature would be
> treated as a new feature along the associated values and raw values.
>
> Please take a look at an example to illustrate this:
> ```swift
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> ```
>
> Similar feature is currently available for example in Java
> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>
> Currently there are at least tree ways to solve this limitation.
>
> 1. use enumeration type with custom struct as a rawValue cons:
> a lot of additional code to define structs and implement
> `ExpressibleByStringLiteral`
> not really possible for more complex types, where a complex string parser
> would be required
>
> example:
> ```swift
> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> public init(stringLiteral value: String) {
> let set = CharacterSet(charactersIn: "x")
> let values = value.components(separatedBy: set)
> if let width = Int(values[0]), let height = Int(values[1]) {
> self.init(width: width, height: height)
> } else {
> self.init(width: 0, height: 0)
> }
> }
> init(extendedGraphemeClusterLiteral value: String){
> self.init(stringLiteral: value)
> }
> init(unicodeScalarLiteral value: String) {
> self.init(stringLiteral: value)
> }
> static func ==(lhs: 

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

[Mateusz Malczak via swift-evolution]

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 need to get that
additional
information you will use switch or rawValue. On one hand we currently
do have an enums with associated values, where you can attach
different values with single enum case. On the other hand we do have
enums with rawType where you can already store some information in
enum cases. Having possibility to store properties would just be an
extension to the rawType case.

> What could you do with this special enum - what would the code that
> uses it look like?
I don't see it as special type of enums, its more or less the same
case as accessing rawValue property (please look at my examples in
initial mail). You can think of them as enums that are able carry over
some more information than only a RawType value.

Let me once again share a code from initial proposal email :
enum Format {
case SMALL(30, 30)
case MEDIUM(60, 60)
case LARGE(120, 120)
var width: Double
var height: Double
init(width: Double, height: Double) {
self.width = width
self.height = height
}
}

In that example you have an enum carrying over some extra informations.

regards
--
| Mateusz Malczak


2016-10-10 2:03 GMT+02:00 Jay Abbott :
> Mateusz,
>
> 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. What could you do with this special enum - what would the code that
> uses it look like?
>
>
>
> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>  wrote:
>>
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
>> and I think it works quite well.
>>
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
>>   private let unFormat : FormatBacking
>>
>>   static var Small : Format {
>> return Format(unFormat: .SMALL(30, 30))
>>   }
>>
>>   static var Medium : Format {
>> return Format(unFormat: .MEDIUM(60, 60))
>>   }
>>
>>   static var Large : Format {
>> return Format(unFormat: .LARGE(120, 120))
>>   }
>>
>>   var width : Int {
>> switch self.unFormat {
>> case let .SMALL(w, _):
>>   return w
>> case let .MEDIUM(w, _):
>>   return w
>> case let .LARGE(w, _):
>>   return w
>> }
>>   }
>>
>>   var height : Int {
>> switch self.unFormat {
>> case let .SMALL(_, h):
>>   return h
>> case let .MEDIUM(_, h):
>>   return h
>> case let .LARGE(_, h):
>>   return h
>> }
>>   }
>> }
>>
>> Yeah, you’re still subject the switching stuff you mentioned before, but I
>> don’t think this is a whole lot of code.  Java’s constants are convenient
>> but they are an oddly structural feature in a particularly nominal language
>> which makes it not scale particularly cleanly.
>>
>> ~Robert Widmann
>>
>> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution
>>  wrote:
>>
>> I agree, you can achieve similar result using structs (as shown in my
>> example 2). But it feels more natural to define it using an
>> enumeration type. Enumeration defines a type with well defined set of
>> possible values. Sometimes where are additional informations liked
>> with enumeration cases (like in example). Using structs for this is
>> more like a walk-around because you are using an open type to mimic a
>> closed set of possible value. What do you think about that?
>>
>> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>>
>> This is precisely what a struct is for, why would you want to be able to
>> do this with enums instead?
>>
>> Hi all,
>> I would like to know you opinion on one feature I feel would be a real
>> 'nice to have' extension to currently available enumeration type. Which is
>> an enumeration type with stored properties. It is sometimes useful to store
>> some extra informations along with enumeration cases. Idea here is to add
>> possibility to define an enumeration type with stored, immutable,
>> properties, defined at compile time for all cases. In opposition to
>> currently available associated values, stored properties should be constant
>> values stored as a part of enumeration case. Proposed feature would be
>> treated as a new feature along the associated values and raw values.
>>
>> Please take a look at an example to illustrate this:
>> ```swift
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>> ```
>>
>> Similar feature is currently 

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

[David Hart via swift-evolution]

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 to the varying 
> elements. 
> 
> Now, I end up creating a secondary struct T and doing case a(T, whatever), 
> b(T, whatever), c(T, whatever), etc. where the same associated structure is 
> every case, *or* I end up putting the enum into a struct which means the 
> guiding semantics are the struct and not the enumeration. Both approaches are 
> ugly. 
> 
> -- E
> 
>> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution 
>> > wrote:
>> 
>> Mateusz,
>> 
>> 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. What could you do with this special enum - what would the code that 
>> uses it look like?
>> 
>> 
>> 
>> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution 
>> > wrote:
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and 
>> I think it works quite well.
>> 
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

I would love to be able to have stored properties in addition to the varying 
elements. 

Now, I end up creating a secondary struct T and doing case a(T, whatever), b(T, 
whatever), c(T, whatever), etc. where the same associated structure is every 
case, *or* I end up putting the enum into a struct which means the guiding 
semantics are the struct and not the enumeration. Both approaches are ugly. 

-- E

> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> Mateusz,
> 
> 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. What could you do with this special enum - what would the code that 
> uses it look like?
> 
> 
> 
> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution 
> > wrote:
> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and 
> I think it works quite well.
> 
> struct Format {
>   enum FormatBacking {
> case SMALL(Int, Int)
> case MEDIUM(Int, Int)
> case LARGE(Int, Int)
>   }

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

Mateusz,

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. What could you do with this special enum - what would the
code that uses it look like?



On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
> and I think it works quite well.
>
> struct Format {
>   enum FormatBacking {
> case SMALL(Int, Int)
> case MEDIUM(Int, Int)
> case LARGE(Int, Int)
>   }
>   private let unFormat : FormatBacking
>
>   static var Small : Format {
> return Format(unFormat: .SMALL(30, 30))
>   }
>
>   static var Medium : Format {
> return Format(unFormat: .MEDIUM(60, 60))
>   }
>
>   static var Large : Format {
> return Format(unFormat: .LARGE(120, 120))
>   }
>
>   var width : Int {
> switch self.unFormat {
> case let .SMALL(w, _):
>   return w
> case let .MEDIUM(w, _):
>   return w
> case let .LARGE(w, _):
>   return w
> }
>   }
>
>   var height : Int {
> switch self.unFormat {
> case let .SMALL(_, h):
>   return h
> case let .MEDIUM(_, h):
>   return h
> case let .LARGE(_, h):
>   return h
> }
>   }
> }
>
> Yeah, you’re still subject the switching stuff you mentioned before, but I
> don’t think this is a whole lot of code.  Java’s constants are convenient
> but they are an oddly structural feature in a particularly nominal language
> which makes it not scale particularly cleanly.
>
> ~Robert Widmann
>
> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
>
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>
> This is precisely what a struct is for, why would you want to be able to
> do this with enums instead?
>
> Hi all,
> I would like to know you opinion on one feature I feel would be a real
> 'nice to have' extension to currently available enumeration type. Which is
> an enumeration type with stored properties. It is sometimes useful to store
> some extra informations along with enumeration cases. Idea here is to add
> possibility to define an enumeration type with stored, immutable,
> properties, defined at compile time for all cases. In opposition to
> currently available associated values, stored properties should be constant
> values stored as a part of enumeration case. Proposed feature would be
> treated as a new feature along the associated values and raw values.
>
> Please take a look at an example to illustrate this:
> ```swift
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> ```
>
> Similar feature is currently available for example in Java (
> http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>
> Currently there are at least tree ways to solve this limitation.
>
> 1. use enumeration type with custom struct as a rawValue cons:
> a lot of additional code to define structs and implement
> `ExpressibleByStringLiteral`
> not really possible for more complex types, where a complex string parser
> would be required
>
> example:
> ```swift
> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> public init(stringLiteral value: String) {
> let set = CharacterSet(charactersIn: "x")
> let values = value.components(separatedBy: set)
> if let width = Int(values[0]), let height = Int(values[1]) {
> self.init(width: width, height: height)
> } else {
> self.init(width: 0, height: 0)
> }
> }
> init(extendedGraphemeClusterLiteral value: String){
> self.init(stringLiteral: value)
> }
> init(unicodeScalarLiteral value: String) {
> self.init(stringLiteral: value)
> }
> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
> }
> static let A = FormatStruct(width: 30, height: 30)
> }
> enum Format: FormatStruct {
> case SMALL = "30x30"
> case MEDIUM = "60x60"
> case LARGE = "120x120"
> var width: Int {
> return rawValue.width
> }
> var height: Int {
> return rawValue.height
> }
> }
> ```
>
> 2. static struct values to mimic enumeration type
> cons:
> enum should be used to define a closed set of 

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

[Robert Widmann via swift-evolution]

I’ve started doing this to try and mimic “Smart Constructors” in Haskell and I 
think it works quite well.

struct Format {
  enum FormatBacking {
case SMALL(Int, Int)
case MEDIUM(Int, Int)
case LARGE(Int, Int)
  }
  private let unFormat : FormatBacking

  static var Small : Format {
return Format(unFormat: .SMALL(30, 30))
  }

  static var Medium : Format {
return Format(unFormat: .MEDIUM(60, 60))
  }

  static var Large : Format {
return Format(unFormat: .LARGE(120, 120))
  }

  var width : Int {
switch self.unFormat {
case let .SMALL(w, _):
  return w
case let .MEDIUM(w, _):
  return w
case let .LARGE(w, _):
  return w
}
  }

  var height : Int {
switch self.unFormat {
case let .SMALL(_, h):
  return h
case let .MEDIUM(_, h):
  return h
case let .LARGE(_, h):
  return h
}
  }
}

Yeah, you’re still subject the switching stuff you mentioned before, but I 
don’t think this is a whole lot of code.  Java’s constants are convenient but 
they are an oddly structural feature in a particularly nominal language which 
makes it not scale particularly cleanly.

~Robert Widmann

> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution 
>  wrote:
> 
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
> 
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>> This is precisely what a struct is for, why would you want to be able to do 
>> this with enums instead?
>> 
>>> Hi all,
>>> I would like to know you opinion on one feature I feel would be a real 
>>> 'nice to have' extension to currently available enumeration type. Which is 
>>> an enumeration type with stored properties. It is sometimes useful to store 
>>> some extra informations along with enumeration cases. Idea here is to add 
>>> possibility to define an enumeration type with stored, immutable, 
>>> properties, defined at compile time for all cases. In opposition to 
>>> currently available associated values, stored properties should be constant 
>>> values stored as a part of enumeration case. Proposed feature would be 
>>> treated as a new feature along the associated values and raw values.
>>> 
>>> Please take a look at an example to illustrate this:
>>> ```swift
>>> enum Format {
>>> case SMALL(30, 30)
>>> case MEDIUM(60, 60)
>>> case LARGE(120, 120)
>>> var width: Double
>>> var height: Double
>>> init(width: Double, height: Double) {
>>> self.width = width
>>> self.height = height
>>> }
>>> }
>>> ```
>>> 
>>> Similar feature is currently available for example in Java 
>>> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>>> 
>>> Currently there are at least tree ways to solve this limitation.
>>> 
>>> 1. use enumeration type with custom struct as a rawValue cons:
>>> a lot of additional code to define structs and implement 
>>> `ExpressibleByStringLiteral`
>>> not really possible for more complex types, where a complex string parser 
>>> would be required
>>> 
>>> example:
>>> ```swift
>>> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
>>> var width: Int = 0
>>> var height: Int = 0
>>> public init(width: Int, height: Int) {
>>> self.width = width
>>> self.height = height
>>> }
>>> public init(stringLiteral value: String) {
>>> let set = CharacterSet(charactersIn: "x")
>>> let values = value.components(separatedBy: set)
>>> if let width = Int(values[0]), let height = Int(values[1]) {
>>> self.init(width: width, height: height)
>>> } else {
>>> self.init(width: 0, height: 0)
>>> }
>>> }
>>> init(extendedGraphemeClusterLiteral value: String){
>>> self.init(stringLiteral: value)
>>> }
>>> init(unicodeScalarLiteral value: String) {
>>> self.init(stringLiteral: value)
>>> }
>>> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
>>> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
>>> }
>>> static let A = FormatStruct(width: 30, height: 30)
>>> }
>>> enum Format: FormatStruct {
>>> case SMALL = "30x30"
>>> case MEDIUM = "60x60"
>>> case LARGE = "120x120"
>>> var width: Int {
>>> return rawValue.width
>>> }
>>> var height: Int {
>>> return rawValue.height
>>> }
>>> }
>>> ```
>>> 
>>> 2. static struct values to mimic enumeration type
>>> cons:
>>> enum should be used to define a closed set of possible values
>>> 
>>> example:
>>> ```swift
>>> struct Format: ExpressibleByStringLiteral, Equatable {
>>> var width: Int = 0
>>> var height: Int = 0
>>> public init(width: Int, height: Int) {
>>> self.width = width
>>> self.height = height
>>> }
>>> static let SMALL 

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

[Mateusz Malczak via swift-evolution]

I agree, you can achieve similar result using structs (as shown in my
example 2). But it feels more natural to define it using an
enumeration type. Enumeration defines a type with well defined set of
possible values. Sometimes where are additional informations liked
with enumeration cases (like in example). Using structs for this is
more like a walk-around because you are using an open type to mimic a
closed set of possible value. What do you think about that?

2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
> This is precisely what a struct is for, why would you want to be able to do 
> this with enums instead?
>
>> Hi all,
>> I would like to know you opinion on one feature I feel would be a real 'nice 
>> to have' extension to currently available enumeration type. Which is an 
>> enumeration type with stored properties. It is sometimes useful to store 
>> some extra informations along with enumeration cases. Idea here is to add 
>> possibility to define an enumeration type with stored, immutable, 
>> properties, defined at compile time for all cases. In opposition to 
>> currently available associated values, stored properties should be constant 
>> values stored as a part of enumeration case. Proposed feature would be 
>> treated as a new feature along the associated values and raw values.
>>
>> Please take a look at an example to illustrate this:
>> ```swift
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>> ```
>>
>> Similar feature is currently available for example in Java 
>> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>>
>> Currently there are at least tree ways to solve this limitation.
>>
>> 1. use enumeration type with custom struct as a rawValue cons:
>> a lot of additional code to define structs and implement 
>> `ExpressibleByStringLiteral`
>> not really possible for more complex types, where a complex string parser 
>> would be required
>>
>> example:
>> ```swift
>> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
>> var width: Int = 0
>> var height: Int = 0
>> public init(width: Int, height: Int) {
>> self.width = width
>> self.height = height
>> }
>> public init(stringLiteral value: String) {
>> let set = CharacterSet(charactersIn: "x")
>> let values = value.components(separatedBy: set)
>> if let width = Int(values[0]), let height = Int(values[1]) {
>> self.init(width: width, height: height)
>> } else {
>> self.init(width: 0, height: 0)
>> }
>> }
>> init(extendedGraphemeClusterLiteral value: String){
>> self.init(stringLiteral: value)
>> }
>> init(unicodeScalarLiteral value: String) {
>> self.init(stringLiteral: value)
>> }
>> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
>> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
>> }
>> static let A = FormatStruct(width: 30, height: 30)
>> }
>> enum Format: FormatStruct {
>> case SMALL = "30x30"
>> case MEDIUM = "60x60"
>> case LARGE = "120x120"
>> var width: Int {
>> return rawValue.width
>> }
>> var height: Int {
>> return rawValue.height
>> }
>> }
>> ```
>>
>> 2. static struct values to mimic enumeration type
>> cons:
>> enum should be used to define a closed set of possible values
>>
>> example:
>> ```swift
>> struct Format: ExpressibleByStringLiteral, Equatable {
>> var width: Int = 0
>> var height: Int = 0
>> public init(width: Int, height: Int) {
>> self.width = width
>> self.height = height
>> }
>> static let SMALL = FormatStruct(width: 30, height: 30)
>> static let MEDIUM = FormatStruct(width: 60, height: 60)
>> static let LARGE = FormatStruct(width: 120, height: 120)
>> }
>> ```
>>
>> 3. define enum with getters
>> cons:
>> additional, repeated `switch` clauses in getters
>>
>> example:
>> ```swift
>> enum Format2 { case SMALL case MEDIUM case LARGE var width: Int { switch 
>> self { case .SMALL: return 30 case .MEDIUM: return 60 case .LARGE: return 
>> 120 } } var height: Int { switch self { case .SMALL: return 30 case .MEDIUM: 
>> return 60 case .LARGE: return 120 } } }
>> ```
>>
>> What is your opinion on this feature? Or maybe that was not implemented for 
>> some reason - if so can I get an few word of explaination what was the 
>> motivation for not adding this to the language?
>>
>> best regards
>> --
>> | Mateusz Malczak___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tim Vermeulen via swift-evolution]

This is precisely what a struct is for, why would you want to be able to do 
this with enums instead?

> Hi all,
> I would like to know you opinion on one feature I feel would be a real 'nice 
> to have' extension to currently available enumeration type. Which is an 
> enumeration type with stored properties. It is sometimes useful to store some 
> extra informations along with enumeration cases. Idea here is to add 
> possibility to define an enumeration type with stored, immutable, properties, 
> defined at compile time for all cases. In opposition to currently available 
> associated values, stored properties should be constant values stored as a 
> part of enumeration case. Proposed feature would be treated as a new feature 
> along the associated values and raw values.
> 
> Please take a look at an example to illustrate this:
> ```swift
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> ```
> 
> Similar feature is currently available for example in Java 
> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
> 
> Currently there are at least tree ways to solve this limitation.
> 
> 1. use enumeration type with custom struct as a rawValue cons:
> a lot of additional code to define structs and implement 
> `ExpressibleByStringLiteral`
> not really possible for more complex types, where a complex string parser 
> would be required
> 
> example:
> ```swift
> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> public init(stringLiteral value: String) {
> let set = CharacterSet(charactersIn: "x")
> let values = value.components(separatedBy: set)
> if let width = Int(values[0]), let height = Int(values[1]) {
> self.init(width: width, height: height)
> } else {
> self.init(width: 0, height: 0)
> }
> }
> init(extendedGraphemeClusterLiteral value: String){
> self.init(stringLiteral: value)
> }
> init(unicodeScalarLiteral value: String) {
> self.init(stringLiteral: value)
> }
> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
> }
> static let A = FormatStruct(width: 30, height: 30)
> }
> enum Format: FormatStruct {
> case SMALL = "30x30"
> case MEDIUM = "60x60"
> case LARGE = "120x120"
> var width: Int {
> return rawValue.width
> }
> var height: Int {
> return rawValue.height
> }
> }
> ```
> 
> 2. static struct values to mimic enumeration type
> cons:
> enum should be used to define a closed set of possible values
> 
> example:
> ```swift
> struct Format: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> static let SMALL = FormatStruct(width: 30, height: 30)
> static let MEDIUM = FormatStruct(width: 60, height: 60)
> static let LARGE = FormatStruct(width: 120, height: 120)
> }
> ```
> 
> 3. define enum with getters
> cons:
> additional, repeated `switch` clauses in getters
> 
> example:
> ```swift
> enum Format2 { case SMALL case MEDIUM case LARGE var width: Int { switch self 
> { case .SMALL: return 30 case .MEDIUM: return 60 case .LARGE: return 120 } } 
> var height: Int { switch self { case .SMALL: return 30 case .MEDIUM: return 
> 60 case .LARGE: return 120 } } }
> ```
> 
> What is your opinion on this feature? Or maybe that was not implemented for 
> some reason - if so can I get an few word of explaination what was the 
> motivation for not adding this to the language?
> 
> best regards
> --
> | Mateusz Malczak___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mateusz Malczak via swift-evolution]

Hi all,
I would like to know you opinion on one feature I feel would be a real
'nice to have' extension to currently available enumeration type. Which is
an enumeration type with stored properties. It is sometimes useful to store
some extra informations along with enumeration cases. Idea here is to add
possibility to define an enumeration type with stored, immutable,
properties, defined at compile time for all cases. In opposition to
currently available associated values, stored properties should be constant
values stored as a part of enumeration case. Proposed feature would be
treated as a new feature along the associated values and raw values.

Please take a look at an example to illustrate this:
```swift
enum Format {
case SMALL(30, 30)
case MEDIUM(60, 60)
case LARGE(120, 120)
var width: Double
var height: Double
init(width: Double, height: Double) {
self.width = width
self.height = height
}
}
```

Similar feature is currently available for example in Java (
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).

Currently there are at least tree ways to solve this limitation.

1. use enumeration type with custom struct as a rawValue cons:
a lot of additional code to define structs and implement
`ExpressibleByStringLiteral`
not really possible for more complex types, where a complex string parser
would be required

example:
```swift
struct FormatStruct: ExpressibleByStringLiteral, Equatable {
var width: Int = 0
var height: Int = 0
public init(width: Int, height: Int) {
self.width = width
self.height = height
}
public init(stringLiteral value: String) {
let set = CharacterSet(charactersIn: "x")
let values = value.components(separatedBy: set)
if let width = Int(values[0]), let height = Int(values[1]) {
self.init(width: width, height: height)
} else {
self.init(width: 0, height: 0)
}
}
init(extendedGraphemeClusterLiteral value: String){
self.init(stringLiteral: value)
}
init(unicodeScalarLiteral value: String) {
self.init(stringLiteral: value)
}
static func ==(lhs: FormatStruct, rhs: FormatStruct) -> Bool {
return (lhs.width == rhs.width) && (lhs.height == rhs.height)
}
static let A = FormatStruct(width: 30, height: 30)
}
enum Format: FormatStruct {
case SMALL = "30x30"
case MEDIUM = "60x60"
case LARGE = "120x120"
var width: Int {
return rawValue.width
}
var height: Int {
return rawValue.height
}
}
```

2. static struct values to mimic enumeration type
cons:
enum should be used to define a closed set of possible values

example:
```swift
struct Format: ExpressibleByStringLiteral, Equatable {
var width: Int = 0
var height: Int = 0
public init(width: Int, height: Int) {
self.width = width
self.height = height
}
static let SMALL = FormatStruct(width: 30, height: 30)
static let MEDIUM = FormatStruct(width: 60, height: 60)
static let LARGE = FormatStruct(width: 120, height: 120)
}
```

3. define enum with getters
cons:
additional, repeated `switch` clauses in getters

example:
```swift
enum Format2 { case SMALL case MEDIUM case LARGE var width: Int { switch
self { case .SMALL: return 30 case .MEDIUM: return 60 case .LARGE: return
120 } } var height: Int { switch self { case .SMALL: return 30 case
.MEDIUM: return 60 case .LARGE: return 120 } } }
```

What is your opinion on this feature? Or maybe that was not implemented for
some reason - if so can I get an few word of explaination what was the
motivation for not adding this to the language?

best regards
--
| Mateusz Malczak
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution