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

[Andrew Bennett]

I like the idea.

I think I'd be using typealias a lot to make things more concise, but
that's not necessarily a problem.

How would I name the following parameter?

    struct OrderedCollection<T: Comparable> {
    }

As I understand it, would I do it as follows?

    struct OrderedCollection<Element: T: Comparable> {
    }

Or would all type constraints now require `where`, like this:
    struct OrderedCollection<Element: T where T: Comparable> {
    }

Also, a typealias seems somewhat redundant when the parameter is labelled:

    struct OrderedCollection<Element: T where T: Comparable> {
        typealias Element = T
    }

I wonder if the typealias could be implied.


On Sun, Jan 24, 2016 at 9:52 AM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Sat Jan 23 2016, David Sweeris <swift-evolution at swift.org> wrote:
>
> > The title seems fairly self-explanatory. Does anyone else think this
> could be useful?
> > struct True : BooleanType {…} // Just part of the example… not in the
> proposal (although I do like it)
> > struct False : BooleanType {…}  // Same
> > // This is where the actual idea starts
> > struct BigInt <BaseType: T = Int, CanEqualZero: U = Yes where T:
> IntegerArithmeticType, U: BooleanType> {…}
> >
> > 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). Then variables could be
> > declared like this:
> > let foo =   BigInt()      // BigInt<Int, No>()
> > let bar =   BigInt<Int32>() // For when your data will be processed on a
> 32-bit platform or something
> > let divisor = BigInt<CanEqualZero: False>()
> >
> > (The obvious follow-up suggestion is to then allow a generic type’s
> > definition to change based on the results of logical operations
> > performed purely on the types that are passed in, but I think that’s
> > getting into “macro system” territory, and should probably be its own
> > thing.)
> >
> > Anyway, thoughts?
> >
>
> +1
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/8e911bb9/attachment.html>