> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about
> the exact same thing.
Good to hear — read that post later, but I guess repeating doesn't hurt here:
People still talk about macros... ;-)
>> So while I think they’re both great features to have, I assume the core team
>> will have higher priorities on their schedule, as I don’t see how these
>> features wouldn’t eat up most resources for at least (!) one Swift
>> release-cycle.
>
> That’s just it: the core team is already prioritizing a lot of features that
> would greatly benefit from this. In fact, if this would be implemented, a
> large portion of the swift compiler could be moved into the standard library,
> because it wouldn’t be magic any more. This would single-handedly reduce the
> implementation time and effort of most proposals by a very large margin.
… and I like specific examples ;-), so out of my head, four features that
people want to have and that could be added easily with "Meta-Swift":
- Forwarding of protocol conformance (Kotlin, for example, has this: When a
member conforms to a protocol, you don't have to write a bunch of methods that
just say "let my member do this")
- init with reduced boilerplate
- Subtyping for non-class types, including a "newtype" option
- Property behaviours
Imho the reflection capabilities that are needed to make the feature fly are
the big tasks — using this information shouldn't be that hard, as it's just a
explicit way of telling the compiler what to do.
Assuming that reflection will be improved anyways, it might be a very cheap
feature with huge benefit.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
