> On 2 Jun 2016, at 7:38 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > Would those who dislike ad hoc enums argue that this also shouldn't be > allowed: > > func foo(bar: (x: Int, y: Int)) {} > let t: (x: Int, y: Int) = (x: 5, y: 5)
I would argue that example contains a code smell, so while it compiles, I personally wouldn’t allow it. But it depends on the semantics of course. And there should always be a pull as a writer to turn a tuple into a struct. My issue with ad hoc enums is that their context is to the function. They should instead be an independent concept, and that’s why an enum type is so useful, because it even names the concept. Tuples from what I see are primarily function based, so it’s really overcoming the fact that while you can pass multiple parameters to a function, you only get one back, so a tuple is the best way to solve that. (And of course they work with callbacks too, an asynchronous version of returning from a function, or functions that alter and return their input). As soon as you start passing a tuple around, it has meaning, and our job as programmers is to assign names and flesh out meaning. And if you are translating from (.fit | .fill) to (.fit | .fill | .florp), that’s a lot of boilerplate code, which goes against the whole reason for having ad hoc enums (or just imagine going the opposite way, there’s a lot more to be discussed on how ad hoc enums work I think). It would be better in mind to break them up into thoughtful pieces, such as two enums or an enum and an extra bool. This isn’t always easy of course. Them’s the breaks! Patrick _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
