Placing type bounds before the name of the thing you are trying to declare
feels unnatural to me. And the generic block is far too much boilerplate!
How about supporting type aliases as Scala does? So you write:
type MyT = Clone + Eq
fn foo<MyT, U>(t: T, u: U) -> …
and the 'type' is just an alias for any type that has Clone + Eq?
Obviously the above only solves repeating yourself for complex type
constraints.
Also, reusing 'for' would be confusing as well, because you expect a loop
there, not a generic type bound. How about 'any':
any <T: Clone + Eq, U> fn foo (t: T, u: U) -> …
?
On Sat, Feb 1, 2014 at 11:06 PM, Benjamin Striegel
<ben.strie...@gmail.com>wrote:
> Another point in favor of this plan is that it would eliminate the need to
> put type parameters directly after the `impl`, which to be honest *is*
> pretty weird and inconsistent with the rest of the language. But I'm still
> not sure how I feel about the look of it:
>
> for <T: Clone+Eq, U> fn foo(t: T, u: U) -> (T, U) {
>
> If you choose *not* to wrap after the type parameters there, you're really
> obscuring what the heck you're trying to declare.
>
> Heck, maybe what we're really asking for is for the ability to have
> "generic blocks" within which type parameters can be declared once:
>
> for <T: Clone+Eq, U> {
> fn foo(t: T, u: U) -> (T, U) {
>
> ...but that's even *more* boilerplate!
>
>
>
>
> On Sat, Feb 1, 2014 at 5:59 PM, Benjamin Striegel
> <ben.strie...@gmail.com>wrote:
>
>> > Yes, and I don't have a solution for that.
>>
>> Well, it's not like we don't already stumble here a bit, what with
>> requiring ::<> instead of just <>. Not sure how much other people value the
>> consistency here.
>>
>>
>> On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson <co...@octayn.net>wrote:
>>
>>> On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
>>> <ben.strie...@gmail.com> wrote:
>>> > First of all, why a new keyword? Reusing `for` here would be totally
>>> > unambiguous. :P And also save us from creating the precedent of
>>> multi-word
>>> > keywords.
>>> >
>>>
>>> I'd be equally happy with for instead of forall.
>>>
>>> > Secondly, currently Rust has a philosophy of use-follows-declaration
>>> (i.e.
>>> > the syntax for using something mirrors the syntax for declaring it).
>>> This
>>> > would eliminate that.
>>> >
>>>
>>> Yes, and I don't have a solution for that.
>>>
>>
>>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
