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

[David Sweeris]

I think it’d more readable to move type constraints to the where clause, but I don’t know if it needs to be a requirement.

I really like your implicit typealias idea…
struct Foo<Element: T, _: U where T: Comparable> {
    // implicit typealias Element = T
    typealias Bar = U // not implicit because U didn’t have a label
}

On Jan 23, 2016, at 19:18, Andrew Bennett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:

> 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 <mailto:swift-evolution at swift.org>> wrote:
> 
> on Sat Jan 23 2016, David Sweeris <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/674687a2/attachment.html>