> On Dec 6, 2017, at 7:41 AM, Vincent Esche via swift-evolution > <swift-evolution@swift.org> wrote: > > If Swift had a rock-solid Generics system at this point and plenty of support > for Meta-Programming via hygienic example-based or procedural macros and/or > compiler plugins, then I'd be way less concerned about this feature getting > misused. > > Alas while Swift's generics provide a nice basic foundation, they still have > big gaps in what can be expressed through them. > And i'm not talking about HKT or any such more advanced use of types). I'm > talking about the basic stuff. Generic abstractions over type conversion. > Generic abstractions over arithmetic operators. This kind of stuff. Stuff, > that ironically would be necessary for a generic yet idiomatic implementation > of Linear Algebra algorithms in Swift. > > I would prefer to get these gaps filled up before providing an orthogonal > feature that can easily be misinterpreted as a solution to the deficits in > Swift's generics system by someone coming from a dynamic language and/or > doesn't fully understand the use of generics. > > We'd in essence be providing what looks like a solution in a time where > thousands of people are looking for workarounds to the limited expressiveness > of Swift's type system. That's like handing out bottles of Methanol for its > use as a household item in a time of severe drought. What could possibly go > wrong?
I think a more appropriate analogy would be to tools, rather than a toxic chemical during times of drought (I would hope the DynamicMemberLookup or DynamicCallable protocols won't result in any fatalities ;). Granted, I only have minimal woodworking experience so some details may be off. Let's say someone only has a hacksaw and circular saw. They're going to have to use these to do jobs that they shouldn't because they have no other option. Now, if someone is thinking about getting them a jigsaw, but says, "Well, they might use this jigsaw for things that a bandsaw or table saw would be more appropriate for, so let's wait until they get a bandsaw and table saw before giving them a jigsaw." Now they're still using inappropriate tools for the cases that a jigsaw would be suitable for. It would make more sense to give them the jigsaw to broaden the appropriate toolset, and then once they get the bandsaw and table saw they'll immediately stop using the jigsaw for those situations. To me, the nastiest thing about the Swift standard library's internal implementation are gyb files. Admittedly, these solve a far more onerous problem than what this proposal is solving, but they're still a pretty ugly solution that come with problems of their own. But the people most excited and motivated to replace these with the appropriate solutions are the ones that wrote them or have to work with them (https://twitter.com/AirspeedSwift/status/936289022766333952). If people do end up using this as a workaround for some missing generics or type system feature, I imagine they would be the first to enthusiastically adopt the appropriate tools once they're available. And the great thing about software is that we can go back and actually change the tools we use to solve the same problem. > It's also a completely different situation than what (from my understanding) > C# was in when they added `dynamic`. I think this relates to a previous message I sent: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042018.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042018.html> Even with all the generic and reflective features in C# at the time, that author found it useful for simplifying code that didn't have anything to do with dynamic language support.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
