On 12-12-30 08:35 PM, Patrick Walton wrote:

> The way to fix this is to change the code to:
> 
>     fn main() {
>         let x = Constructible::new();
>     }
> 
> This state of affairs strikes me as confusing to C++/Java/C# users, who
> might be expecting the methods to be available in `Foo` as well as the
> `Constructible` interface. Indeed this was the case in earlier versions
> of Rust (and is the case today in some cases), but I worry that this
> feature is dangerous, as we might want our type to later implement a
> different typeclass with a different method called `new` and there would
> then be a name clash.

This is a bit of a gotcha, true. It looks a little less zany if you
write Constructible::new::<Foo>().

I don't think there's anything much you can do to make it less
surprising, in terms of the decl site. Users are going to expect
_static_ methods to be scoped to the type, not the trait, no matter how
you declare it. I agree with your rationale for why _not_ to do that,
but I don't think you can avoid the surprise.

Type::static_method() is how it works in the languages you're concerned
with users from (it's why the "factory pattern" exists!) and IMO anyone
who knows that will be surprised by Trait::static_method() with the
concrete type inferred (or parameterized). It surprises me every time I
see it, despite my belief that it's a superior feature :)

> I understand that there was an objection last time this syntax was
> brought up that our trait syntax in generics is `T:Trait`, and therefore
> it's more consistent to say `impl T : Trait`. However, it seems to me
> that the situation back then is different from the situation now in
> these ways:
> 
> ...

These are interesting but, to my eyes, don't make a clear case for any
particular arrangement; as I said above, I think twiddling the decl site
isn't going to make it any less of a toe-stub. And I still find the
"mirror the generic type-constraint form" argument most compelling for
the decl.

Minor preference, anyway. Not a hill I'll die on, but traits as
type-constraints seems to me like a good hint.

-Graydon

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to