[swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values

Tino Heth 2th at gmx.de
Sun Jan 24 05:08:50 CST 2016


Hi David,

> struct BigInt <BaseType: T = Int, CanEqualZero: U = Yes where T: IntegerArithmeticType, U: BooleanType> {…}
Is the "Yes" an error and it should be "True" instead?

> The first parameter label could be skipped (or not), depending on whatever the rules for functions parameter labels ends up being (either way, they should be the same IMHO).
I don't think the rules have to be identical:
Methods are often verbs, so often, there is a natural "target" whose meaning can be inferred from the method name.
Generics are different — they "don't tell a story", and although there are situations where it seems one parameter is more relevant than the others ("BaseType" in you example), it would be odd to declare "BigIntWithBaseType<…".

I guess when there is a single parameter, its meaning is clear in most cases, but when you have more parameters, you cannot assume that the first should be treated different from the second (neither would it make sense to always treat them in the same way.

Every label useful:
let vector: Map<Index = UInt, Content = Double>

No label useful:
class Comparer<L: BooleanType, R: BooleanType>

It's to hard for the compiler to decide what should be done, and in such situations, my lazy solution is always "leave the decision to the user".

I guess I'm to slow building my stupid litte proposal — but even if I haven't written an example for instantiation yet, I came to the same conclusion that labels can be useful for generics  (https://github.com/SwiftTypesafeCalculations/Home/wiki/compile-time%20parameters <https://github.com/SwiftTypesafeCalculations/Home/wiki/compile-time%20parameters>).
Your use case might benefit from it as well: afaics, "True" and "False" are only there to "lift" true and false into type-space, qualifying them as parameters.

Please feel free to comment or even co-author on "compile-time parameters" — I'm not sure I'll be bold enough to turn it into a real pull-request without external pressure ;-)
(afair, you already posted in the thread ["typesafe calculations"])

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/02cdeba7/attachment.html>


More information about the swift-evolution mailing list