Re: [rust-dev] Another idea on requiring mut prefix at call site

2014-05-01 Thread Noam Yorav-Raphael
Just because I still think it might be a good idea -- if it turns out to be a good idea, it will be possible to add such a mut annotation to rust 1.1 and issue a warning if it is not being used, right? Noam On Apr 30, 2014 3:31 PM, Noam Yorav-Raphael noamr...@gmail.com wrote: Actually I realize

[rust-dev] Once_fns

2014-05-01 Thread Valerii Hiora
Hi, Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQit mentioned as experimental feature, which might not be enabled in 1.0. But it is Compiler shows a warning ___ Rust-dev

Re: [rust-dev] Once_fns

2014-05-01 Thread Valerii Hiora
I apologize for sending draft, here goes the full version. Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQthey are mentioned as experimental feature, which might not be enabled in 1.0. Compiler shows a warning once

[rust-dev] How does Windows is supported?

2014-05-01 Thread John Mija
Is possible to create wraps to the Windows system calls? Is there any tool to do it easily? Something like [mksyscall_windows.go](https://code.google.com/p/go/source/browse/src/pkg/syscall/mksyscall_windows.go) which generates the bodies for the Windows system calls.

Re: [rust-dev] morestack prologue contains broken machine code

2014-05-01 Thread Vladimir Pouzanov
Is there any good reason why kSplitStackAvailable is hard-coded to 256 (given that I have tasks with their whole stack on 512 bytes)? I guess, this constant should actually be externally configurable. On Fri, Apr 25, 2014 at 5:20 PM, Alex Crichton a...@crichton.co wrote: The prologue is run on

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Mikhail Zabaluev
Hi, 2014-05-01 16:53 GMT+03:00 Malthe Borch mbo...@gmail.com: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. Meanwhile, building on experience with Python 2 and 3, I think it's worth considering a more flexible design. A string

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Nathan Myers
It would be a mistake for a byte sequence container, stream, or string type to know anything about particular encodings. An encoding is an interpretation imposed on a byte sequence. Users of a sequence need to be able to choose what interpretation to apply without interference from some

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Malthe Borch
On Thursday, May 1, 2014, Nathan Myers n...@cantrip.org wrote: It would be a mistake for a byte sequence container, stream, or string type to know anything about particular encodings. An encoding is an interpretation imposed on a byte sequence. Users of a sequence need to be able to choose

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Tony Arcieri
On Thu, May 1, 2014 at 6:53 AM, Malthe Borch mbo...@gmail.com wrote: A string would be essentially a rope where each leaf specifies an encoding, e.g. UTF-8 or ISO8859-1 (ideally expressed as one or two bytes). That is, a string may be comprised of segments of different encodings. Oh god

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Malthe Borch
On 1 May 2014 21:03, Tony Arcieri basc...@gmail.com wrote: Oh god no! Please no. This is what Ruby does and it's a complete nightmare. This creates an entire new class of bug when operations are performed on strings with incompatible encodings. It's an entire class of bug that simply doesn't

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Malthe Borch
On 1 May 2014 18:54, Mikhail Zabaluev mikhail.zabal...@gmail.com wrote: I don't think that so much hidden complexity would be justified in the built-in string type. Encoded text is typically dealt with in protocol libraries or similar I/O barriers where it should be passed through a validating

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Tony Arcieri
On Thu, May 1, 2014 at 1:06 PM, Malthe Borch mbo...@gmail.com wrote: This is not the case in the proposed design. You're wrong. All string operations would behave exactly as if there was only a single encoding. The only requirement is that the strings are properly declared with an

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Daniel Micay
On 01/05/14 09:53 AM, Malthe Borch wrote: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. Meanwhile, building on experience with Python 2 and 3, I think it's worth considering a more flexible design. A string would be essentially

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Steve Klabnik
Yes, this is what Ruby does, and yes, it causes a lot of tears. It's one of the biggest things that made the 1.8 - 1.9 transition difficult. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Malthe Borch
On 1 May 2014 22:42, Tony Arcieri basc...@gmail.com wrote: No, when you combine strings with different encodings, you need to transcode one of the strings. When this happens, the transcoding process may encounter some characters which are valid in one encoding, but not another, in which case

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Patrick Walton
On 5/1/14 6:53 AM, Malthe Borch wrote: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. Meanwhile, building on experience with Python 2 and 3, I think it's worth considering a more flexible design. A string would be essentially a rope

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread John Downey
I have actually always been a fan of how .NET did this. The System.String type is opinionated in how it is stored internally and does not allow anyone to change that (unlike Ruby). The conversion from String to byte[] is done using explicit conversion methods like: -

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Tony Arcieri
On Thu, May 1, 2014 at 2:45 PM, Malthe Borch mbo...@gmail.com wrote: The transcoding needs to happen only at the time when you flatten the rope into a single encoding. And yes, it may then fail if you attempt to encode into a non-unicode encoding. This sounds like the exact same painful

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Thad Guidry
Agreed with Patrick. This proposal should not be in std::str ... it can live somewhere else...but not there. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ On Thu, May 1, 2014 at 4:52 PM, Patrick Walton pcwal...@mozilla.com

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Nathan Myers
On 05/01/2014 02:52 PM, Patrick Walton wrote: On 5/1/14 6:53 AM, Malthe Borch wrote: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. ... A string would be essentially a rope where each leaf specifies an encoding, e.g. UTF-8 or

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Daniel Micay
On 01/05/14 07:49 PM, Nathan Myers wrote: On 05/01/2014 02:52 PM, Patrick Walton wrote: On 5/1/14 6:53 AM, Malthe Borch wrote: In Rust, the built-in std::str type is a sequence of unicode codepoints encoded as a stream of UTF-8 bytes. ... A string would be essentially a rope where each leaf

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Tony Arcieri
On Thu, May 1, 2014 at 4:49 PM, Nathan Myers n...@cantrip.org wrote: The history of programming languages is littered with mistakes around string types. There's no reason why Rust must repeat them all. FWIW, I've worked in systems that work the way you describe, and I disagree and think

Re: [rust-dev] UTF-8 strings versus encoded ropes

2014-05-01 Thread Nathan Myers
On 05/01/2014 04:57 PM, Daniel Micay wrote: On 01/05/14 07:49 PM, Nathan Myers wrote: In defining a library string we always grapple over how it should differ from a raw (variable or fixed) array of bytes. Ease of appending and of assigning into substrings always comes up. In the old days,