It is very easy to create a language that is unwieldy, but hard to create something KISS simple that can be adopted, and that will be praised for its cleanliness and elegance. If the basic things are not simple, a language will be relegated to academia, and will not be as popular as hoped. We really need to take a look into this one, and come up with something workable. That won't be easy considering what Patrick has mentioned. Sent from my BlackBerry 10 smartphone.
Send Rust-dev mailing list submissions to
[email protected] To subscribe or unsubscribe via the World Wide Web, visit https://mail.mozilla.org/listinfo/rust-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Rust-dev digest..." Today's Topics: 1. PSA: ~"string" is probably not what you want (Patrick Walton) 2. Re: PSA: ~"string" is probably not what you want (Lee Braiden) 3. Re: PSA: ~"string" is probably not what you want (Patrick Walton) 4. Re: PSA: ~"string" is probably not what you want (Daniel Micay) ---------------------------------------------------------------------- Message: 1 Date: Sun, 28 Apr 2013 10:45:04 -0700 From: Patrick Walton <[email protected]> To: "[email protected]" <[email protected]> Subject: [rust-dev] PSA: ~"string" is probably not what you want Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Just thought I'd give the mailing list a heads up that ~"string", besides being ugly, is generally inefficient: it allocates a string on the heap and frees it when it goes out of scope. There are no optimizations that eliminate the allocation. If you need to compare a `~str` against a constant string, use .equiv(): use core::cmp::Equiv; fn main() { let x = ~"foo"; if "foo".equiv(&x) { println("yep"); } } This should admittedly be imported by default. Patrick ------------------------------ Message: 2 Date: Sun, 28 Apr 2013 18:57:38 +0100 From: Lee Braiden <[email protected]> To: [email protected] Subject: Re: [rust-dev] PSA: ~"string" is probably not what you want Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 28/04/13 18:45, Patrick Walton wrote: > If you need to compare a `~str` against a constant string, use .equiv(): > > use core::cmp::Equiv; > > fn main() { > let x = ~"foo"; > if "foo".equiv(&x) { > println("yep"); > } > } > > This should admittedly be imported by default. Really? Strings can't just be compared with == ? To be honest, that alone is almost enough to put me off the language -- not only is it ugly and unwieldy, but it suggests a lot of limitations in the language's memory model / type system / operator overloading, which would also make my own code ugly and unwieldy. What's the problem with ==, or the difference with equiv(), exactly? Is there some way to make it just work, no matter what kind of strings you're comparing? Perhaps "foo" == (*x) would work, for example? -- Lee ------------------------------ Message: 3 Date: Sun, 28 Apr 2013 11:14:13 -0700 From: Patrick Walton <[email protected]> To: [email protected] Subject: Re: [rust-dev] PSA: ~"string" is probably not what you want Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 4/28/13 10:57 AM, Lee Braiden wrote: > Really? Strings can't just be compared with == ? To be honest, that > alone is almost enough to put me off the language -- not only is it ugly > and unwieldy, but it suggests a lot of limitations in the language's > memory model / type system / operator overloading, which would also make > my own code ugly and unwieldy. > > What's the problem with ==, or the difference with equiv(), exactly? The problem is that `&str` and `~str` are not the same type. We could change `Eq` so that it doesn't require the same type on the left-hand-side and the right-hand-side, but that would complicate the trait system quite a bit. Currently, overloaded operators do not borrow. I guess we could change overloaded operators (or maybe just `==` and `!=`?) to try to borrow the left hand side and/or right hand side to make the types match. I think this is *probably* OK. However, we need to be careful, because it's exactly the kind of thing that could have unforeseen consequences. "Strings should be comparable with `==` without allocating" is the kind of thing that is "obviously true", but trying to do it without thinking carefully about the ramifications of borrowing in overloaded operators is problematic. We already have quite complex method lookup semantics exactly to make things like this just work, and it has fallout when you start having to get picky about how many dereferences you do. To be honest, the tone of your message is a little frustrating, because you jumped on one thing that's not ideal (that the different types `~str` and `&str` cannot be compared with `==`), said something inaccurate (that strings cannot be compared with `==`), and extrapolated it to the idea that Rust's type system is "ugly and unwieldy". No, it's just that we need to think carefully about how to handle this one case. > Is > there some way to make it just work, no matter what kind of strings > you're comparing? Perhaps "foo" == (*x) would work, for example? That doesn't work, because it makes the dynamically sized `str` a type, which is incoherent. (It would lead to dynamically sized stack frames, or structs or enums with infinite size, and so on.) Patrick ------------------------------ Message: 4 Date: Sun, 28 Apr 2013 14:35:40 -0400 From: Daniel Micay <[email protected]> To: Lee Braiden <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [rust-dev] PSA: ~"string" is probably not what you want Message-ID: <ca+dvkq+okucru3howqjlhaoveidqc0rfhiwy2bmfev1vhsi...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Sun, Apr 28, 2013 at 1:57 PM, Lee Braiden <[email protected]> wrote: > On 28/04/13 18:45, Patrick Walton wrote: >> >> If you need to compare a `~str` against a constant string, use .equiv(): >> >> use core::cmp::Equiv; >> >> fn main() { >> let x = ~"foo"; >> if "foo".equiv(&x) { >> println("yep"); >> } >> } >> >> This should admittedly be imported by default. > > > Really? Strings can't just be compared with == ? To be honest, that alone > is almost enough to put me off the language -- not only is it ugly and > unwieldy, but it suggests a lot of limitations in the language's memory > model / type system / operator overloading, which would also make my own > code ugly and unwieldy. > > What's the problem with ==, or the difference with equiv(), exactly? Is > there some way to make it just work, no matter what kind of strings you're > comparing? Perhaps "foo" == (*x) would work, for example? > > > -- > Lee Strings and vectors are special cased in the syntax, ~"foo" and ~("foo") aren't the same type. This issue is specific to the string/vector implementations included in the language, it's a non-issue with borrowed pointers or owned/shared boxes. Eq doesn't take a type parameter for the right-hand side parameter, so if ~"str" is on the left-hand side the right-hand side has to be ~"str" too. Although a ~str can be borrowed as a slice so "foo" == ~"foo" *will* work. Eq *could* take a type parameter like Add, Sub, etc. - it just doesn't right now. ------------------------------ _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev End of Rust-dev Digest, Vol 34, Issue 92 **************************************** | ||
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
