On Wed, May 01, 2013 at 02:39:12PM +0200, Gábor Lehel wrote:
> I also just read Niko's blog post, and I'm not sure which thread to reply
> in (or who to reply to), but I guess I'll do it here. Niko's message here
> beforehand was kind of expectations-downplaying, but reading the blog post,
> his proposed scheme seems to allow more or less the same as what I was
> asking about here (perhaps minus the user-defined dynamically sized types,
> but that was icing).
Yeah, I wasn't sure how well that idea of changing the representation
for all vecs/strings would work out, but then in the process of
writing the post I decided it worked out quite well. It was an idea I
first had last summer when we were hashing this out the first time,
and have been meaning to chew on for some time, so I'm glad we had
this thread on the mailing list to bring it back to my mind.
> So *if* the plan ends up working out, then taking the second part of my
> earlier proposal:
>
> > You might also have a rule whereby dereferencing a variable when the
> > result would be a dynamically-sized type is allowed *if* the result is
> > immediately borrowed. Then instead of `impl Eq for {@str, ~str, &str}`,
> > you would have just `impl Eq for str`, and if you want to compare an
> > ~str you dereference it.
>
> Would that work? Would it be a good solution?
I believe that would be the plan, yes. Most of these
"apply-to-almost-everything"
traits, like `Eq` or `Ord`, could be implemented in a similar fashion.
I'm not sure what problem you are proposing this as a solution *for*,
though. Do you mean the problem of comparing strings using `==`?
I suppose it is true that under this proposal you could write
let str1: ~str = ~"hi";
let str2: &str = "hi";
*str1 == *str2
and it would work fine. That is a nice side-effect I hadn't
considered.
*An aside:* Note that dereferencing a pointer to an unsized object is
only allowed in an "lvalue" context (that is, when we are taking its
address):
let str1: ~str = ~"hi";
let foo = *str1; // ERROR
let bar = &*str1; // OK
Here, `foo` is an error because `*str1` is being evaluated in an
rvalue context, but `bar` is fine, because `*str1` is being evaluted
in an lvalue context. In the case of `==`, this works out because the
arguments to overloaded operators are always passed by reference.
*A further aside:* don't be misled by my use of the term
"lvalue context" into thinking that a program like this would
be legal:
let mut str1: ~str = ~"Hello";
*str1 = "World"; // ERROR
This is illegal because assigning to an lvalue of unsized type is
illegal, even though `*str1` appears in an lvalue context.
regards,
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
