<div dir="ltr">Is this what you're trying to achieve, only using a nicer syntax to represent it?<br><a href="http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831">http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831</a><br><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak <<a href="mailto:mateusz@malczak.info">mateusz@malczak.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think, I have used quite unfortunate naming, which is a root of an<br class="gmail_msg">
misunderstanding here. By saying 'enums with stored properties' what I<br class="gmail_msg">
was really thinking about, was enumeration type with stored constant,<br class="gmail_msg">
immutable properties (constants). I don't want to duplicate 'struct'<br class="gmail_msg">
type here, but instead I would like to make it possible to store a<br class="gmail_msg">
const values in enumeration cases. So going back to my example once<br class="gmail_msg">
again:<br class="gmail_msg">
<br class="gmail_msg">
Lest define an enumeration type `Format` with 3 possible cases. Each<br class="gmail_msg">
case will be able to carry over some additional information - in this<br class="gmail_msg">
case a pair of numbers (but in fact Any? should be possible)<br class="gmail_msg">
<br class="gmail_msg">
enum Format {<br class="gmail_msg">
case SMALL(30, 30)<br class="gmail_msg">
case MEDIUM(60, 60)<br class="gmail_msg">
case LARGE(120, 120)<br class="gmail_msg">
var width: Double<br class="gmail_msg">
var height: Double<br class="gmail_msg">
init(width: Double, height: Double) {<br class="gmail_msg">
self.width = width<br class="gmail_msg">
self.height = height<br class="gmail_msg">
}<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
I'm not sure about 'var' clause in that example as it causes all the confusion.<br class="gmail_msg">
<br class="gmail_msg">
I can access additional info stored in enum case, but it cannot be<br class="gmail_msg">
modified. Format.SMALL doesn't change, as well as non of its<br class="gmail_msg">
properties.<br class="gmail_msg">
<br class="gmail_msg">
// allowed usage<br class="gmail_msg">
let format = Format.SMALL<br class="gmail_msg">
let width = format.width // this would be equal to 30 (const value<br class="gmail_msg">
assigned to 'width' property on enum case .SMALL)<br class="gmail_msg">
<br class="gmail_msg">
// not allowed usage<br class="gmail_msg">
let format = Format.SMALL<br class="gmail_msg">
format.width = 40 // error, stored values are immutable and can not be modified<br class="gmail_msg">
<br class="gmail_msg">
We get all advantages of enumeration type, and, assuming all cases are<br class="gmail_msg">
describing the same possible state, we can store some extra<br class="gmail_msg">
information in each case. This can be called a third enumeration type<br class="gmail_msg">
feature, right next to associated values and rawType.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
| Mateusz Malczak<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
2016-10-10 13:40 GMT+02:00 Jay Abbott <<a href="mailto:jay@abbott.me.uk" class="gmail_msg" target="_blank">jay@abbott.me.uk</a>>:<br class="gmail_msg">
> Thanks for the explanation Mateusz, I think I understand. So the enum still<br class="gmail_msg">
> only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some<br class="gmail_msg">
> properties?<br class="gmail_msg">
><br class="gmail_msg">
> So some code to use it might be:<br class="gmail_msg">
> var aFormat = Format.LARGE<br class="gmail_msg">
> aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change<br class="gmail_msg">
><br class="gmail_msg">
> Is that right?<br class="gmail_msg">
><br class="gmail_msg">
> On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution<br class="gmail_msg">
> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hi,<br class="gmail_msg">
>> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties<br class="gmail_msg">
>> > on<br class="gmail_msg">
>> > enums is the solution: that looks very ugly to me too.<br class="gmail_msg">
>><br class="gmail_msg">
>> That may look ugly, but can be very useful, if only you think<br class="gmail_msg">
>> rawValue's are useful then you should also agree that stored<br class="gmail_msg">
>> properties would be useful :)<br class="gmail_msg">
>><br class="gmail_msg">
>> --<br class="gmail_msg">
>> | Mateusz Malczak<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution<br class="gmail_msg">
>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>:<br class="gmail_msg">
>> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties<br class="gmail_msg">
>> > on<br class="gmail_msg">
>> > enums is the solution: that looks very ugly to me too.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution<br class="gmail_msg">
>> > <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > I would love to be able to have stored properties in addition to the<br class="gmail_msg">
>> > varying<br class="gmail_msg">
>> > elements.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Now, I end up creating a secondary struct T and doing case a(T,<br class="gmail_msg">
>> > whatever),<br class="gmail_msg">
>> > b(T, whatever), c(T, whatever), etc. where the same associated structure<br class="gmail_msg">
>> > is<br class="gmail_msg">
>> > every case, *or* I end up putting the enum into a struct which means the<br class="gmail_msg">
>> > guiding semantics are the struct and not the enumeration. Both<br class="gmail_msg">
>> > approaches<br class="gmail_msg">
>> > are ugly.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > -- E<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution<br class="gmail_msg">
>> > <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Mateusz,<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > To me, "Enumeration defines a type with well defined set of possible<br class="gmail_msg">
>> > values"<br class="gmail_msg">
>> > seems to contradict the idea of having properties that can have<br class="gmail_msg">
>> > different<br class="gmail_msg">
>> > values. What could you do with this special enum - what would the code<br class="gmail_msg">
>> > that<br class="gmail_msg">
>> > uses it look like?<br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution<br class="gmail_msg">
>> > <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> I’ve started doing this to try and mimic “Smart Constructors” in<br class="gmail_msg">
>> >> Haskell<br class="gmail_msg">
>> >> and I think it works quite well.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> struct Format {<br class="gmail_msg">
>> >> enum FormatBacking {<br class="gmail_msg">
>> >> case SMALL(Int, Int)<br class="gmail_msg">
>> >> case MEDIUM(Int, Int)<br class="gmail_msg">
>> >> case LARGE(Int, Int)<br class="gmail_msg">
>> >> }<br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > _______________________________________________<br class="gmail_msg">
>> > swift-evolution mailing list<br class="gmail_msg">
>> > <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
>> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > _______________________________________________<br class="gmail_msg">
>> > swift-evolution mailing list<br class="gmail_msg">
>> > <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
>> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>> ><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-evolution mailing list<br class="gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>