I wonder if the idea of using ref by default in patterns for Copyless
types has being considered? The need to move on pattern match should
be infrequent. So it is better to use a special syntax for that case
skipping box ref and similar in most of the code.
On 28 May 2014 06:23, Corey Richardson
Hi,
How to find number of characters in a string?
Following example returns byte count instead of number of characters.
use std::string::String;
fn main() {
let unicode_str = String::from_str(ಅ);
let ascii_str = String::from_str(a);
println!(unicode str: {},
On 2014-05-28, at 11:10 , Aravinda VK hallimanearav...@gmail.com wrote:
Hi,
How to find number of characters in a string?
Problem 1: define character. Do you mean a glyph? A grapheme cluster? A
code point? Composed or decomposed?
Problem 2: what use is knowing the length of a string?
Thanks. I didn't know about char_len. `unicode_str.as_slice().char_len()`
is giving number of code points.
Sorry for the confusion, I was referring codepoint as character in my mail.
char_len gives the correct output for my requirement. I have written
javascript script to convert from string
pnkfelix et al,
Thanks for your work on the graphviz module! It's a great asset to my
flowgraph DSL work.
I'm wondering if any consideration has been given to
Decodable/Encodable-style bidirectional serialization and deserialization.
It'd be great to be able to use existing apps (like
And there's a good chance we'll add auto-deref+autoref for function
arguments, specifically so String will auto-slice to str the same way ~str
used to (although someone still needs to write up an RFC for this).
I would like the devs to clarify their support for this proposal, since I
have seen
I think that the naming of `len` here is dangerously misleading. Naive
ASCII-users will be free to assume that this is counting codepoints rather
than bytes. I'd prefer the name `byte_len` in order to make the behavior
here explicit.
On Wed, May 28, 2014 at 5:55 AM, Simon Sapin
On 28/05/14 10:07 AM, Benjamin Striegel wrote:
I think that the naming of `len` here is dangerously misleading. Naive
ASCII-users will be free to assume that this is counting codepoints
rather than bytes. I'd prefer the name `byte_len` in order to make the
behavior here explicit.
It doesn't
On 28/05/2014 15:13, Daniel Micay wrote:
On 28/05/14 10:07 AM, Benjamin Striegel wrote:
I think that the naming of `len` here is dangerously misleading. Naive
ASCII-users will be free to assume that this is counting codepoints
rather than bytes. I'd prefer the name `byte_len` in order to make
It's .len() because slicing and other related functions work on byte indexes.
We've had this discussion before in the past. People expect there to be a
.len(), and the only sensible .len() is byte length (because char length is not
O(1) and not appropriate for use with most string-manipulation
People expect there to be a .len()
This is the assumption that I object to. People expect there to be a .len()
because strings have been fundamentally broken since time immemorial. Make
people type .byte_len() and be explicit about their desire to index via
code units.
On Wed, May 28, 2014 at
Breaking with established convention is a dangerous thing to do. Being too
opinionated (regarding opinions that deviate from the norm) tends to put people
off the language unless there's a clear benefit to forcing the alternative
behavior.
In this case, there's no compelling benefit to naming
Being too opinionated (regarding opinions that deviate from the norm)
tends to put people off the language unless there's a clear benefit to
forcing the alternative behavior.
We have already chosen to be opinionated by enforcing UTF-8 in our strings.
This is an extension of that break with
Benjamin seems to say that folks won't read the docs and we need to make
the syntax more helpful..
Kevin seems to say that we need to keep the syntax simple and just teach
folks to read the docs.
I think I would agree with both of them overall for a language design goal
that Rust wants to
On May 28, 2014, at 11:55 AM, Benjamin Striegel ben.strie...@gmail.com wrote:
Being too opinionated (regarding opinions that deviate from the norm) tends
to put people off the language unless there's a clear benefit to forcing
the alternative behavior.
We have already chosen to be
There's no clear tradition regarding strings.
Excellent, then surely nobody has any right to expect a method named .len()
:)
Unicode is not a simple concept. UTF-8 on the other hand is a pretty
simple concept.
I don't think we can fully divorce these two ideas. Understanding UTF-8
still
On May 28, 2014, at 1:26 PM, Benjamin Striegel ben.strie...@gmail.com wrote:
Unicode is not a simple concept. UTF-8 on the other hand is a pretty simple
concept.
I don't think we can fully divorce these two ideas. Understanding UTF-8 still
implies understanding the difference between
Do you honestly believe
Yes. Anyone who comes to Rust expecting there to be a .len() method on
strings has demonstrated that they fundamentally misunderstand what strings
are. Correcting them will be a learning experience, to their benefit.
more verbose, annoying, unconventional names
I
On 29/05/14 06:38, Kevin Ballard wrote:
On May 28, 2014, at 1:26 PM, Benjamin Striegel ben.strie...@gmail.com
mailto:ben.strie...@gmail.com wrote:
Unicode is not a simple concept. UTF-8 on the other hand is a
pretty simple concept.
I don't think we can fully divorce these two ideas.
On May 28, 2014, at 3:24 PM, Huon Wilson dbau...@gmail.com wrote:
Changing the names of methods on strings seems very similar how Path does not
implement Show (except with even stronger motivation, because strings have at
least 3 sensible interpretations of what the length could be).
I
Hi!
I've just recently started learning Rust. Here's a few questions that
I have after writing about a hundred lines of code:
1. Why neither overloaded function, nor default values for arguments
are supported? In statically typed language overloaded functions are
quite safe and convenient. Also,
A few quick intro answers. Just the high level, not comprehensive.
1. Not everyone prefers overloaded functions, or default arguments. I
know pcwalton has strong feelings about the first, so I'll leave him
to that :)
2. Design decision. Basically, we take Erlang's philosophy: recovering
from
On 5/28/14 5:38 PM, Oleg Eterevsky wrote:
7. The usage of mut is a bit confusing. It is supposed to be used as a
qualifier for a variable, but it quickly becomes a part of the type,
when you define functions like
fn test(something: mut Something)
Maybe it makes sense move mut their? Or
Oh and while we're belligerently bikeshedding, we should rename `to_str` to
`to_string` once we rename `StrBuf` to `String`. :)
On Wed, May 28, 2014 at 9:00 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
but people will still end up calling the
*exact same method*
...Except when they
On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky o...@eterevsky.com wrote:
3. It seems like almost any string operation requires as_slice().
Can't various string methods be also implemented for String?
When writing functions for others to use, you don't want to require them to
have a String,
You can also read and search the docs and easily see the Implementors (and
even click on them to get more detailed documentation AND even have 1 click
access to the [src] ) :
http://doc.rust-lang.org/0.10/std/to_str/trait.ToStr.html
If you find the docs are lacking a bit, then let the
Thanks for your answers. Can't say I understand or agree with all the decisions.
1. Not everyone prefers overloaded functions, or default arguments.
Suppose, I want to add a new argument to a function in a
backwards-compatible way. In Python I provide a default and everything
works fine. In C++
Maybe it makes sense move mut their? Or distinguish mut as a variable
qualifier vs const as a propery of type?
The way it is implemented in Rust is necessary for memory safety.
Are there any articles on this? I'd like to know more. :)
On Wed, May 28, 2014 at 5:48 PM, Patrick Walton
When writing functions for others to use, you don't want to require them to
have a String, since that requires a heap allocation.
By no means. I'd prefer the same functions to work both on str and
String. It should be possible to achieve it via traits.
This is because ToStr is implemented
Thanks, I already read some parts of documentation. It is good, though
I found the navigation a bit confusing. I also looked at the sources
for libcore and libstd on GitHub, they are very readable. (Compared
to, for instance, STL.)
By the way, I remembered one more question that I had:
I am a
On May 28, 2014, at 6:00 PM, Benjamin Striegel ben.strie...@gmail.com wrote:
To reiterate, it simply doesn't make sense to ask what the length of a string
is. You may as well ask what color the string is, or where the string went to
high school, or how many times the string rode the roller
On May 28, 2014, at 5:38 PM, Oleg Eterevsky o...@eterevsky.com wrote:
4. It looks like vectors can be concatenated with + operations, but
strings can't. Is it deliberate?
Partially. It's fallout of all the changes that strings have been going through
lately. And [PR #14482][] reintroduces +
On 2014-05-29 05:36, Kevin Ballard wrote:
[--snip--]
And when dealing with a sequence in a precise encoding, the natural unit to
work
with is the code unit (and this has precedence in other languages,
such as JavaScript, Obj-C, and Go).
JavaScript:
$ node
var s = hï; // Note the
Thanks for the detailed reply.
I agree that overloaded functions can be used to shoot yourself in the
foot. Fortunately, I haven't yet seen any code that I would care to
read, designed so badly that overloaded functions would do essentially
different things depending on the number or type of
Hi all, I don't suggest seeing Javascript as a great example for Rust.
It uses UTF-16, but was created back when UTF-16 was UCS-2, so
two-code-unit codepoints are poorly supported in Javascript (e.g. you
can't use them in regex character classes).
On 05/29/2014 12:16 AM, Bardur Arantsson
On May 28, 2014, at 9:16 PM, Bardur Arantsson s...@scientician.net wrote:
Rust:
$ cat
fn main() {
let l = hï.len(); // Note the accent
println!({:u}, l);
}
$ rustc hello.rs
$ ./hello
3
No matter how defective the notion of length may be, personally I
think that
36 matches
Mail list logo
