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

[David Sweeris]

Response inlined...
> On Jan 24, 2016, at 03:08, Tino Heth <2th at gmx.de> wrote:
> 
> 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?
Yep. I guess that’s what I get for changing my mind half-way through writing something :-)

>> 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 hadn't enough thought to the formal syntax. What I'd originally posted had a lot of colons by the time it was all typed out. Should we just copy the syntax from function arguments? So the external label would default to being the same as the parameter name, unless you put a "_" in front of it or provided a different one? Seems like a waste to come up with two different syntaxes for two concepts that are so similar (plus, I think of generics as "compile-time arguments" anyway).

Either way, I think parameters with default types would need to also have an external label, for the same reason that function arguments with default values can't externally be "_".

And, as Andrew suggested, anything with an explicit external label gets implicitly typealiased.

> 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).
> Your use case might benefit from it as well: affairs, "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

Yeah, if that goes through (I really hope it does), those True/False types wouldn't be needed.

I'll take a closer look at your formal proposal as soon as I get a chance and let you know if I think I can contribute to it :-)

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/8c82ac6b/attachment.html>