[swift-evolution] Proposal: Stored properties for enums

Jonathan Hise Kaldma info at hisekaldma.com
Thu Dec 10 08:54:29 CST 2015


If it's important to keep sum and product types separate, perhaps this could be a new type entirely. A "composite" perhaps?

Best,
Jonathan

> 10 dec. 2015 kl. 14:53 skrev Al Skipp <al_skipp at fastmail.fm>:
> 
> 
>> On 10 Dec 2015, at 12:34, Jonathan Hise Kaldma <info at hisekaldma.com> wrote:
>> 
>> Not really. It certainly works, but it's hard to follow. Also, this example was imagining some type of editor with blocks on a timeline. So the pos and length should really be properties of the block, not of the data.
> 
> Fair enough : )
> 
> I’d definitely be keen to maintain the distinction between product types and sum types and this proposal seems to lose that. If pattern matching on product types were introduced, it should solve this particular conundrum. Here’s how it could potentially look in Haskell using pattern matching in the ‘doStuff’ function. Not sure how the pattern matching would look in Swift, but this gives an impression of what’s possible.
> 
> 
> data BlockType = Audio AudioData | Video VideoData
> 
> data Block = Block { dataType :: BlockType, pos :: Double, len :: Double }
> 
> doStuff :: Block -> IO ()
> doStuff Block {dataType = (Audio audioData), pos = p, len = l} = … function implementation using audioData, p and l
> doStuff Block {dataType = (Video videoData), pos = p, len = l} = … function implementation using videoData, p and l


More information about the swift-evolution mailing list