Would also need to add an `impl<T: Clone + Eq> MyT for T`, so we've
gone in a circle.
On Sat, Feb 1, 2014 at 6:16 PM, Benjamin Striegel
<ben.strie...@gmail.com> wrote:
>> How about supporting type aliases as Scala does?
>
> In theory I think that should be achievable today, using trait inheritance:
>
> trait MyT : Clone, Eq {}
>
> ...at least, I *think* we allow multiple trait inheritance. Not sure what
> the syntax is!
>
>
> On Sat, Feb 1, 2014 at 6:12 PM, Vladimir Lushnikov
> <vladi...@slate-project.org> wrote:
>>
>> 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
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
