3 ms·

> Note that in this specific case you could just use `&str` over `&String` everywhere It's an awkwardly construed example. Here is the actual code - https://gi

by jamii 11y ago

> Note that in this specific case you could just use `&str` over `&String` everywhere It's an awkwardly construed example. Here is the actual code - https://gist.github.com/jamii/ae46e8e0c9757330e9ea https://gist.github.com/jamii/ae46e8e0c9757330e9ea . There the borrow makes more sense since the value is being created by calling a function on the current solver state. I've edited the post to include a solution that was suggested in the reddit discussion - replace &'a Value with Cow<'a, Value>. > It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing. > Actually where clauses are much more powerful. I really don't understand this part of the language yet, but... I linked to an active rfc about constraints that cannot currently be expressed in where clauses (https://github.com/rust-lang/rfcs/blob/master/text/0135-where.md https://github.com/rust-lang/rfcs/blob/master/text/0135-wher...), including the example you gave. In cases where a function takes two arguments it isn't always obvious which argument should be self. If that affects whether constraints end up being A: Foo<B> or B: Foo<A> or `where Foo<A,B>` it seems like one could run up against those limitations?

niconii 11y ago
I think you may have misread that RFC. With my emphasis: > Here is a list of limitations with the current bounds syntax that are overcome with the where syntax: The list is of the limitations of normal bounds, not the limitations of where clauses. This was actually the RFC that added where clauses, and that list was the rationale for doing so.
- jamii 11y ago
  Oh... well that's embarrassing. So, I half-remembered the actual problem I ran into and found something that half-looked like it mentioned it. Not my finest hour :S I dug up the IRC exchange for the problem I actually ran into: jamii How do I write the type of a byte iterator: fn next_path<N: Iterator>(nibbles: &mut N) -> u32 where <N as Iterator>::Item = u8 { That gives me 'equality constraints are not yet supported' FreeFull jamii: <N: Iterator<Item = u8>> Equality constraints seem to still be unimplemented ( https://github.com/rust-lang/rust/pull/22074 https://github.com/rust-lang/rust/pull/22074) but I can write this instead where N : Iterator<Item=u8> So that whole section of the post is incorrect. I've removed it and linked to this discussion instead.
  - jroesch 11y ago
    I'm the author of the above pull request (as well as other pieces of where clauses), unfortunately there are some internals that need refactoring before we can complete equality constraints, and they weren't the highest priority before 1.0 especially since you can encode a trait that acts in the same way. I'm starting at Mozilla for the summer next week and hope to fix a couple of the outstanding issues around them and associated types.
Manishearth 11y ago
> There the borrow makes more sense since the value is being created by calling a function on the current solver state. Agreed. And yes, a Cow is better in this case though of course there's a slight runtime cost. In such a case I would heavily document the new invariants with warning comments though :P > I linked to an active rfc about constraints that cannot currently be expressed in where clauses Those are the constraints that cannot currently be expressed in bounds, not where clauses. Bounds are the stuff within <>, where clauses were the new thing proposed to supplement them. > In cases where a function takes two arguments it isn't always obvious which argument should be self. I'm not sure why you seem to be troubled by self (here and in the post). It might be due to you looking at method dispatch as a sugar for function calls -- it sort of is (because of UFCS), but it really isn't. The second argument can never be self. It's always the first. (nitpick: functions can't have self args, methods can, but that's just terminology). For direct impls, you do a method without `self` when you wish it to be a static method. Eg `impl Foo {fn x(){}}` will be a method called as `Foo::x()` and will work independently of any instance of the type. `impl Foo{fn x(self){}}` needs to be called as `foo.x()`, where `foo` is a `Foo`. Here, the method is able to access the state of `foo`. The behavior so far is the same for most languages like python or java (java has implicit self and uses `static` to say "no self"). Now, traits just let you provide a way to classify objects based on what methods -- both self and nonself/static -- they have. So, a trait `Cloneable` would be `trait Cloneable { fn clone(&self) -> Self}`, and its implementation would be `impl Cloneable for Foo {fn clone(&self) -> Foo {....}}`. This would mean that "given a `Foo`, I should be able to get another `Foo` out of it by calling `foo.clone()`". On the other hand, sometimes you want to run an operation on the type itself. I.e. `trait TypeName {fn type_name() -> &'static str}` and is implemented as `impl TypeName for Foo {fn type_name() -> &'static str {"Foo"}}`. In this case, it's no longer "given a `Foo`, do X", it's "given a type that implements TypeName, do X". Generally nonself methods on traits don't make much sense unless you're doing type gymnastics (in fact, Java doesn't even allow static methods in interfaces). For example, they're used in hyper for dynamic dispatch on strongly typed headers (http://hyper.rs/hyper/hyper/header/trait.Header.html http://hyper.rs/hyper/hyper/header/trait.Header.html) Also, `where Foo<A,B>` doesn't make sense, where clauses need a colon; `where Something: SomethingElse`.
- jamii 11y ago

by jamii 11y ago

niconii 11y ago

I think you may have misread that RFC. With my emphasis: > Here is a list of limitations with the current bounds syntax that are overcome with the where syntax: The list is of the limitations of normal bounds, not the limitations of where clauses. This was actually the RFC that added where clauses, and that list was the rationale for doing so.

jamii 11y ago
Oh... well that's embarrassing. So, I half-remembered the actual problem I ran into and found something that half-looked like it mentioned it. Not my finest hour :S I dug up the IRC exchange for the problem I actually ran into: jamii How do I write the type of a byte iterator: fn next_path<N: Iterator>(nibbles: &mut N) -> u32 where <N as Iterator>::Item = u8 { That gives me 'equality constraints are not yet supported' FreeFull jamii: <N: Iterator<Item = u8>> Equality constraints seem to still be unimplemented ( https://github.com/rust-lang/rust/pull/22074 https://github.com/rust-lang/rust/pull/22074) but I can write this instead where N : Iterator<Item=u8> So that whole section of the post is incorrect. I've removed it and linked to this discussion instead.
- jroesch 11y ago
  I'm the author of the above pull request (as well as other pieces of where clauses), unfortunately there are some internals that need refactoring before we can complete equality constraints, and they weren't the highest priority before 1.0 especially since you can encode a trait that acts in the same way. I'm starting at Mozilla for the summer next week and hope to fix a couple of the outstanding issues around them and associated types.

Manishearth 11y ago

> There the borrow makes more sense since the value is being created by calling a function on the current solver state. Agreed. And yes, a Cow is better in this case though of course there's a slight runtime cost. In such a case I would heavily document the new invariants with warning comments though :P > I linked to an active rfc about constraints that cannot currently be expressed in where clauses Those are the constraints that cannot currently be expressed in bounds, not where clauses. Bounds are the stuff within <>, where clauses were the new thing proposed to supplement them. > In cases where a function takes two arguments it isn't always obvious which argument should be self. I'm not sure why you seem to be troubled by self (here and in the post). It might be due to you looking at method dispatch as a sugar for function calls -- it sort of is (because of UFCS), but it really isn't. The second argument can never be self. It's always the first. (nitpick: functions can't have self args, methods can, but that's just terminology). For direct impls, you do a method without `self` when you wish it to be a static method. Eg `impl Foo {fn x(){}}` will be a method called as `Foo::x()` and will work independently of any instance of the type. `impl Foo{fn x(self){}}` needs to be called as `foo.x()`, where `foo` is a `Foo`. Here, the method is able to access the state of `foo`. The behavior so far is the same for most languages like python or java (java has implicit self and uses `static` to say "no self"). Now, traits just let you provide a way to classify objects based on what methods -- both self and nonself/static -- they have. So, a trait `Cloneable` would be `trait Cloneable { fn clone(&self) -> Self}`, and its implementation would be `impl Cloneable for Foo {fn clone(&self) -> Foo {....}}`. This would mean that "given a `Foo`, I should be able to get another `Foo` out of it by calling `foo.clone()`". On the other hand, sometimes you want to run an operation on the type itself. I.e. `trait TypeName {fn type_name() -> &'static str}` and is implemented as `impl TypeName for Foo {fn type_name() -> &'static str {"Foo"}}`. In this case, it's no longer "given a `Foo`, do X", it's "given a type that implements TypeName, do X". Generally nonself methods on traits don't make much sense unless you're doing type gymnastics (in fact, Java doesn't even allow static methods in interfaces). For example, they're used in hyper for dynamic dispatch on strongly typed headers (http://hyper.rs/hyper/hyper/header/trait.Header.html http://hyper.rs/hyper/hyper/header/trait.Header.html) Also, `where Foo<A,B>` doesn't make sense, where clauses need a colon; `where Something: SomethingElse`.

jamii 11y ago