Re: [rust-dev] box syntax question

[Benjamin Striegel]

To expand upon what Corey was saying, `box` is basically a huge
special-cased hack right now. I'm surprised that a mention of `box(GC)` is
even included in the tutorial. Someone tell Steve to rip that out. :P

We'll be clarfiying how best to use `box` before 1.0. In the meantime, just
don't use GC. Like, at all. You don't need it! :)


On Wed, Jul 2, 2014 at 10:39 PM, Corey Richardson  wrote:

> The full syntax is: "box" ["(" EXPR ")"] EXPR
>
> The first expression is the "boxer", or where the result of the second
> expression will be stored. GC and HEAP are special cased right now as
> the only boxers, but the goal is to use a trait such that you can use
> Rc, arenas, vectors, or any other arbitrary type as a boxer.
>
> On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin  wrote:
> > Once in the tutorial, I see this syntax:
> >
> >
> > let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10];
> >
> > It seems to me, that should be: box, as it feels like box is
> referring
> > to a container type (which the default type is Box<_>, but may be Rc<_>
> or
> > Gc<_>).
> >
> > What is the principle behind the current notation? What is "GC" is this
> > context other than a special string that is a one-off syntax?
> > --
> > Oscar Boykin :: @posco :: http://twitter.com/posco
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
>
>
> --
> http://octayn.net/
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust 0.11.0 Released

[Benjamin Striegel]

> Are you starting to support these releases with bug-eliminations?

AFAIK there is no intention to start issuing bugfix releases at this time.
The reason for the extra number at the end is for stricter adherence to
Semantic Versioning, which requires a bugfix number.


On Wed, Jul 2, 2014 at 5:50 PM, Zoltán Tóth  wrote:

> A new number appeared in the version "0.11.0" compared to "0.10". This
> looks like a preparation for "0.11.1", ... . Are you starting to support
> these releases with bug-eliminations?
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust 0.11.0 Released

[Benjamin Striegel]

Well done! 1.0 draws closer every day. I'm giddy with anticipation.


On Wed, Jul 2, 2014 at 2:07 PM, Alex Crichton  wrote:

> Mozilla and the Rust community are pleased to announce version 0.11.0 of
> the Rust compiler and tools. Rust is a systems programming language with a
> focus on safety, performance and concurrency.
>
> While this was a very active development cycle, it was largely focused on
> polishing the type system and libraries. The major technical focuses this
> time were implementing infrastructure for dynamically sized types and
> refactoring the standard library. This release also marks the complete
> removal of the `~` and `@` syntax in favor of library types `Box` and
> `Gc`.
>
> The brief release notes are included in this announcement, and there is
> further explanation in the detailed release [notes] on the wiki.
> Documentation and all the links in this email are available on the
> [website]. As usual, version 0.11.0 should be considered an alpha release,
> suitable for early adopters and language enthusiasts. Please file [bugs]
> and join the [fun].
>
> [website]: http://www.rust-lang.org
> [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes
> [bugs]: https://github.com/mozilla/rust/issues
> [fun]:
> https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors
>
> Source
>
> * http://static.rust-lang.org/dist/rust-0.11.0.tar.gz
>   http://static.rust-lang.org/dist/rust-0.11.0.tar.gz.asc
>   SHA256 (of .tar.gz):
>   d1b3e36448bf12b8c9289024df416de10774b6d3235d7b1d22b248ef634411ba
>
> Windows installer
>
> * http://static.rust-lang.org/dist/rust-0.11.0-install.exe
>   http://static.rust-lang.org/dist/rust-0.11.0-install.exe.asc
>   SHA256 (of .exe):
>   fb253072ba5373eb0af388f63e51122af9dd13379d762ca4100ee7334dbec9d2
>
> Linux binary tarballs
>
> *
> http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz
>
> http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz.asc
>   SHA256 (of .tar.gz):
>   331d6374b3c8fca3e2b5fffb65ce75dfce3529bd47333de4a9ce636cb87be432
>
> *
> http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz
>
> http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz.asc
>   SHA256 (of .tar.gz):
>   cbfe2050f708479f2625a935d2f41165868f354ff740d2697e08acb2255670b2
>
> Mac OS X binary installers
>
> * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg
>   http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg.asc
>   SHA256 (of .pkg):
>   1183d6c8ab021f4049a2906c1527f705bae4bb4935aea897f4860eb5337363c3
>
> * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg
>   http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg.asc
>   SHA256 (of .pkg):
>   8f5a1fe491d83c6be0a3082f0ac8504c89eed38263ae0ac0fad15d8c02e3b267
>
> Mac OS X binary tarballs
>
> * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz
>
> http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz.asc
>   SHA256 (of .tar.gz):
>   bbac91aff5464c20f39afcf078a693c4612717d6b1cc3f86f92075b2103bc22e
>
> * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz
>
> http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz.asc
>   SHA256 (of .tar.gz):
>   93d6e6e98d00df3e946e4f7765172ad522a118dd34f1fac73ba74d43df92698b
>
> Thanks to everyone who contributed!
>
> Regards,
> The Rust Team
>
> Version 0.11.0 (July 2014)
> -
>
>   * ~1700 changes, numerous bugfixes
>
>   * Language
> * ~[T] has been removed from the language. This type is superseded by
>   the Vec type.
> * ~str has been removed from the language. This type is superseded by
>   the String type.
> * ~T has been removed from the language. This type is superseded by the
>   Box type.
> * @T has been removed from the language. This type is superseded by the
>   standard library's std::gc::Gc type.
> * Struct fields are now all private by default.
> * Vector indices and shift amounts are both required to be a `uint`
>   instead of any integral type.
> * Byte character, byte string, and raw byte string literals are now all
>   supported by prefixing the normal literal with a `b`.
> * Multiple ABIs are no longer allowed in an ABI string
> * The syntax for lifetimes on closures/procedures has been tweaked
>   slightly: `<'a>|A, B|: 'b + K -> T`
> * Floating point modulus has been removed from the language; however it
>   is still provided by a library implementation.
> * Private enum variants are now disallowed.
> * The `priv` keyword has been removed from the language.
> * A closure can no longer be invoked through a &-pointer.
> * The `use foo, bar, baz;` syntax has been removed from the language.
> * The transmute intrinsic no longer works on type parameters.
> * Statics now allow blocks/items in their definition.
> *

Re: [rust-dev] Syntax sugar: Vec Rc RefCell Box Foo -> Vec>>>

[Benjamin Striegel]

If the vast majority of types take only a single type parameter, then it
could potentially be worth considering using a unary sigil. (I think D does
something like this.)

Choosing the tilde as the arbitrary symbol here, your example would look
like Arc~Exclusive~Vec~Box~Buffer~T. If you have multiple type parameters,
you would need to wrap them in parens like ~(T, U). Just something to
consider.

Whether or not we want something like this, I'd be fascinated if someone
managed to gather stats on how many types take only a single type parameter.


On Sun, Jun 29, 2014 at 3:06 PM, François-Xavier Bourlet 
wrote:

> Isn't:
>
>type my_convonluted_type = Arc;
>
> The most common way to avoid retyping long definition? one could also
> pretty indent the type definition for readability, since it will be
> defined once.
>
> On Sun, Jun 29, 2014 at 9:56 AM, Benjamin Herr  wrote:
> > I realize that, but simplifying
> >
> > Arc
> >
> > into
> >
> > Arc (Exclusive (Vec (Box (Buffer T
> >
> > wouldn't really buy us that much.
> >
> >
> > On Sun, 2014-06-29 at 09:50 -0700, Cameron Zwarich wrote:
> >> This is pretty confusing to me because it’s associative in the opposite
> direction that function application is associative in functional languages
> with automatic currying.
> >>
> >> Cameron
> >>
> >> On Jun 28, 2014, at 3:48 PM, Benjamin Herr  wrote:
> >>
> >> > So, I've been vaguely concerned that types in a less sigil-heavy Rust
> >> > inevitably devolve into what some call "spikey lisp", and tried to
> come
> >> > up with some more lightweight syntax. Of course, just removing syntax
> is
> >> > the easiest way to make it weigh less, and it seems like the following
> >> > doesn't actually break the grammar dramatically (only some macros!):
> >> >
> >> > In parsing a path, if a path segment is immediately followed by an
> >> > identifier, start parsing another type right away and use it as the
> only
> >> > element of the type parameter list for the current path segment.
> >> >
> >> > This is fairly limited:
> >> >
> >> > * It won't work for absolute paths as type parameters
> >> >  (since they'll look like just another path segment)
> >> > * It also doesn't work for non-path types in type parameter lists
> >> > * It doesn't simplify multiple type parameters
> >> >
> >> > I think that's okay, since it's a simplification that applies well to
> a
> >> > lot of simple cases, and might still reduce the total depth of `<`,
> `>`
> >> > nesting in more complicated cases.
> >> >
> >> > So, for example, the following desugarings would apply:
> >> >
> >> >   Vec String
> >> >=> Vec
> >> >
> >> >   Arc RWLock Vec f64
> >> >=> Arc>>
> >> >
> >> >   Arc Exclusive Vec Box Buffer T
> >> >=> Arc // from libsync
> >> >
> >> >   RefCell DefIdMap Rc Vec Rc TraitRef
> >> >=> RefCell// from librustc
> >> >
> >> >   HashMap
> >> >=> HashMap, Vec>>>
> >> >
> >> >   Add
> >> >=> Add, Complex>
> >> >
> >> >   std::mem::size_of RefCell String()  // maybe a bit much?
> >> >=> std::mem::size_of::>())
> >> >
> >> > I've patched that into libsyntax and `make check` passes...
> >> >
> >> > ... after changing some macros, since it basically means that adjacent
> >> > identifiers parse as a single type (or expression, if we omit `::<>`
> >> > too) and some macros try to match `($x:ty fake_keyword_ident ...)`, or
> >> > have a case for `($x:expr)` and another for `(fake_keyword $x:expr)`,
> or
> >> > just `($t:ty)*`. Seems like just chomping down on all adjacent
> >> > identifiers makes the parser pretty aggressive...
> >> >
> >> > Yeah, okay, I don't know if this is really a good idea, and it's
> >> > probably not RFC-worthy at this point, but imo it does make the
> syntax a
> >> > bit easier on the eyes, and I think that's something we ought to look
> at
> >> > at some point.
> >> >
> >> > ___
> >> > Rust-dev mailing list
> >> > Rust-dev@mozilla.org
> >> > https://mail.mozilla.org/listinfo/rust-dev
> >>
> >
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> the fact is that everyone is an optimist when it comes to integer
overflow bugs.  People just do not think they're going to get bitten.

I agree, and I don't think anyone else here is going to try to argue that
this doesn't cause real bugs. As so often seems to be the case, language
design amounts to deciding which unfortunate tradeoffs you are willing to
live with.


On Mon, Jun 23, 2014 at 8:16 PM, John Regehr  wrote:

> I do think Rust should exposed either `checked { }` or operators for
>> checked arithmetic along with an opt-in lint to deny the unchecked
>> operators. You can opt-out of a lint for a function/impl/module after
>> opting into it at a higher scope.
>>
>> I'm just making it clear that doing this by default would make Rust
>> slower than Java by default, and I think that would kill off interest in
>> the language. I know I wouldn't be interested anymore.
>>
>
> Sure, I think there are a lot of reasonable options here, and I agree that
> speed and predictability are super important for Rust.
>
> One thing I personally think is very important (not for 1.0, but
> eventually) is to make it possible -- no need for this to be mandatory --
> to get overflow checking for the default integer type.  I'm happy to use a
> special compiler flag or whatever to get this.  The only controversial
> thing this requires from the core language is a way for me to tell the
> compiler which integers (a tiny subset, typically) should have wrapping
> behavior.
>
> I realize that safe integers are available and that operator overloading
> goes a lot ways towards making these palatable, but the fact is that
> everyone is an optimist when it comes to integer overflow bugs.  People
> just do not think they're going to get bitten.
>
> Finally, I'll note that certain optimizations such as array bounds check
> removal and some loop optimziations actually get better then integers
> cannot wrap.  Clearly we would not expect, in general, for these benefits
> to make up for the costs of overflow checking.
>
>
> John
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> I feel like Rust might be missing out on the free lunch I expect Swift to
provide

I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest benefactor
of LLVM, which powers the C compiler their OS is built with, the
Objective-C language that all their apps are written in, the IDE used to
write those apps, and the Javascript engine that powers their web browser.
Despite Swift's arrival, I wouldn't expect any greater investment in LLVM
than Apple does currently (which is a shame, given the bazillion dollars
burning a hole in their pocket).

I'd like to also note that Apple has no external incentive to improve
Swift. Objective-C was a dead language before Apple's fiat rocketed it into
the position of world's third-most-popular programming language. Regardless
of Swift's implementation or design decisions, it *will* be one of the most
popular languages in the world come this time next year (likely accompanied
by Objective-C's meteoric descent). If Swift were a fusion of RPG and
Malbolge with an implementation written in INTERCAL, this fact would not
change (thankfully, the Swift designers have better taste). Why bother
straining yourself to satisfy a captive audience, when your only real
competitor is whatever dialect of Java that Dalvik supports?


On Mon, Jun 23, 2014 at 5:08 PM, Tony Arcieri  wrote:

> On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay 
> wrote:
>
>> It would be an enormous mistake to ship a language with region typing /
>>  move semantics and worse before than Java.
>
>
> You keep saying that, but if the argument is to use Swift's approach, i.e.:
>
> Non-overflow operators: + - * / %
>  Overflow operators: &+ &- &* &/ &%
>
> Or let's swap Swift's defaults if you so desire:
>
> Overflow operators: + - * / %
> Non-overflow operators: &+ &- &* &/ &%
>
> Or even change the syntax if you so desire:
>
> Overflow operators: + - * / %
> Non-Overflow operators: +~ -~ *~ /~ %~
>
> ...then any arguments about performance are really a false dichotomy. It's
> just a question of syntax and defaults. Want to perform well at TIOBE or
> other (micro)benchmarks? Use the overflow operators! Want to write safe
> code? Use the checked overflow operators. I really think Rust should
> support both approaches, be it implemented through a type or operator or
> what have you. I'm not here to bikeshed that. I just want to make sure both
> approaches have a first class position in the language, and would generally
> prefer but don't insist upon checked overflow being the default.
>
> If the Rust developers insist on choosing overflow operators as the One
> True Way To Do Math, well, that's your prerogative. I will probably still
> choose Rust over Swift. But then I feel like Rust might be missing out on
> the free lunch I expect Swift to provide, which is sad if that's the way
> the cookie crumbles...
>
> --
> Tony Arcieri
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> Ada's approach to integer overflows is substantially similar to AIR

Isn't Ada's response to overflow implementation-defined?


On Mon, Jun 23, 2014 at 11:37 AM, John Regehr  wrote:

>  I would think that something simple like
>>
>>let mut sum = 0;
>>for x in some_int_array.iter() {
>>sum += x;
>>}
>>
>> would be very hard to vectorise with unwinding integer operations.
>>
>
> It sounds like there are two problems.  First, you need to give up on
> precise exceptions.  So the code becomes something line:
>
>
> let mut sum = 0;
> overflow = false
> for x in some_int_array.iter() {
>   (sum,o) = x+sum
>   overflow |= o
> }
> if (overflow) deal with it
>
> The other problem is that as far as I know AVX doesn't store the overflow
> bits for integer vector operations and recovering these bits another way
> isn't necessarily cheap.
>
> In an earlier mail Patrick said that AIR integers are research and using
> research results is risky.  This is true but keep in mind that Ada's
> approach to integer overflows is substantially similar to AIR, and Ada is
> not a research language.
>
> John
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

I apologize for being hostile. As Florian has noted, we're just arguing
about the default behavior here. It is my opinion that checked behavior by
default will make Rust unsuitable for filling C++'s niche, and send the
message that we are not serious about performance.


On Sun, Jun 22, 2014 at 12:10 PM, Evan G  wrote:

> I don't think I was ever "Railing against the incorrectness of overflow
> semantics"? I was just pointing out that your (imo pretty hostile?) message
> about "If you don't require absolute speed, why are you using Rust?"
> doesn't really ring true. Most C++ programmers don't even require absolute
> speed.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Recoverable and unrecoverable errors (Was: Re: Integer overflow, round -2147483648)

[Benjamin Striegel]

I agree that we need to clarify our error-handling story. Specifically I
would like Daniel to elaborate on this quote of his from the previous
thread, with potential solutions at the language level:

> Rust's task failure isn't very isolated or robust. A failure in a
> destructor called during failure will abort the process. A failure in a
> destructor when not already failing will not call the inner destructors
> as it would be memory unsafe.
>
> A failure also has to poison RWLock / Mutex so that all other threads
> with handles to the same shared data will fail too. I don't think these
> issues are going to be fixed, unwinding in a language with destructors
> is just inherently broken.
>
> I think process separation is a far better option for robust systems.


On Sun, Jun 22, 2014 at 10:29 AM, Gábor Lehel  wrote:

>
> On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay 
> wrote:
>
>> On 21/06/14 07:55 PM, Benjamin Striegel wrote:
>> >> No one will use Rust if it's slow. If it uses checked arithmetic, it
>> >> will be slow. There's nothing subjective about that.
>> >
>> > This is the only argument that matters.
>> >
>> > If we are slower than C++, Rust will not replace C++ and will have
>> > failed at its goal of making the world a safer place. The world already
>> > has a glut of safe and slow languages; if inefficiency were acceptable,
>> > then C++ would have been replaced long ago.
>> >
>> > In addition, bringing up hypothetical CPU architectures with support for
>> > checked arithmetic is not relevant. Rust is a language designed for
>> > 2014, not for 2024.
>> >
>> > And if in 2024 we are all suddenly gifted with CPUs where checked
>> > arithmetic is literally free and if this somehow causes Rust to be
>> > "obsolete" (which seems unlikely in any case), then so be it. Rust is
>> > not the last systems programming language that will ever be written.
>>
>> Not only does the hardware have to provide it, but each OS also has to
>> expose it in a way that Rust could use to throw an exception, unless the
>> proposal is to simply abort on overflow. LLVM would also have to gain
>> support for unwinding from arithmetic operations, as it can't currently
>> do that. Even with hardware support for the operation itself, giving
>> every integer operation a side effect would still cripple performance by
>> wiping out optimizations.
>>
>
> This is going off on a tangent (and I hope editing the subject will make
> gmail consider it a separate conversation), but I've been bothered for a
> while by our apparent lack of distinction between, as I've heard them
> referred to, recoverable and unrecoverable errors. Unrecoverable errors are
> programmer errors. Per their name, they are not recoverable. They don't
> "happen" at runtime, or even compile time, but at program-writing time, and
> the only way to recover from them is to go back to program-writing time and
> fix the program. Things like out-of-bounds array accesses, accidental
> overflow, `assert`s and `debug_assert`s would belong in this category.
> Meanwhile, recoverable errors are merely problems which occur at runtime,
> and it should be possible to recover from them.
>
> Task failure, recoverable from without the task but not within it, is kind
> of neither here nor there.
>
> What if we *did* move to program abort for unrecoverable errors?
>
> And what if we did (eventually) grow an actual exception handling system
> for (some) recoverable errors? We'd enforce the same isolation guarantees
> for `try { }` blocks as we do for tasks - in other words, a `try` block
> couldn't share state with the rest of the function - so exception safety
> would continue to not be a concern. (I know we have `try()`, but it's kind
> of coarse and has an up-front performance cost.) To me, the hard part
> doesn't seem to be exception safety, but figuring out what things can be
> thrown and how they are caught, whether they're part of function signatures
> or exist outside them, and so on. The
> catches-based-on-type-of-thrown-object mechanism used by existing languages
> doesn't appeal to me, but I don't have many better ideas either.
>
>
>
>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> There are plenty of other features to Rust then "absolute speed".

You're right. Here are the three primary features of Rust, in decreasing
order of importance:

1. Memory safety
2. C++ performance
3. Safe concurrency

Notably, correctness in the face of integer overflow is merely a
nice-to-have, and if it would compromise the second principle then we
cannot accept it. The only features that are allowed to compromise
performance are those that are required to satisfy memory safety, and the
developers have already concluded that defined integer overflow does not
jeopardize memory safety. Your only recourse is to convince the developers
that they are incorrect and that overflow semantics are in fact a memory
safety hazard. Railing against the incorrectness of overflow semantics
alone isn't going to sway anyone.


On Sun, Jun 22, 2014 at 11:39 AM, Evan G  wrote:

> Because of memory safety? Because you want low-level control without
> absolute speed? Because of a small memory footprint? Because of having a
> good async story without giving up a lot of speed?
>
>  There are plenty of other features to Rust then "absolute speed". Just
> because that's *your* usecase for it doesn't mean you should force it on
> others.
>
>
> On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel <
> ben.strie...@gmail.com> wrote:
>
>> > Even though Rust is a performance conscious language (since it aims at
>> displacing C and C++), the 80/20 rule still applies and most of Rust code
>> should not require absolute speed
>>
>> This is a mistaken assumption. Systems programming exists on the extreme
>> end of the programming spectrum where edge cases are the norm, not the
>> exception, and where 80/20 does not apply. If you don't require absolute
>> speed, why are you using Rust?
>>
>>
>> On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq <
>> matthieu.monr...@gmail.com> wrote:
>>
>>> I am not a fan of having wrap-around and non-wrap-around types, because
>>> whether you use wrap-around arithmetic or not is, in the end, an
>>> implementation detail, and having to switch types left and right whenever
>>> going from one mode to the other is going to be a lot of boilerplate.
>>>
>>> Instead, why not take the same road than swift and map +, -, * and / to
>>> non-wrap-around operators and declare new (more verbose) operators for the
>>> rare case where performance matters or wrap-around is the right semantics ?
>>>
>>> Even though Rust is a performance conscious language (since it aims at
>>> displacing C and C++), the 80/20 rule still applies and most of Rust code
>>> should not require absolute speed; so let's make it convenient to write
>>> safe code and prevent newcomers from shooting themselves in the foot by
>>> providing safety by default, and for those who profiled their applications
>>> or are writing hashing algorithms *also* provide the necessary escape
>>> hatches.
>>>
>>> This way we can have our cake and eat it too... or am I missing
>>> something ?
>>>
>>> -- Matthieu
>>>
>>>
>>>
>>> On Sun, Jun 22, 2014 at 5:45 AM, comex  wrote:
>>>
>>>> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay 
>>>> wrote:
>>>> >> Er... since when?  Many single-byte opcodes in x86-64 corresponding
>>>> to
>>>> >> deprecated x86 instructions are currently undefined.
>>>> >
>>>> > http://ref.x86asm.net/coder64.html
>>>> >
>>>> > I don't see enough gaps here for the necessary instructions.
>>>>
>>>> You can see a significant number of invalid one-byte entries, 06, 07,
>>>> 0e, 1e, 1f, etc.  The simplest addition would just be to resurrect
>>>> INTO and make it efficient - assuming signed 64 and 32 bit integers
>>>> are good enough for most use cases.  Alternatively, it could be two
>>>> one-byte instructions to add an unsigned version (perhaps a waste of
>>>> precious slots) or a two-byte instruction which could perhaps allow
>>>> trapping on any condition.  Am I missing something?
>>>> ___
>>>> Rust-dev mailing list
>>>> Rust-dev@mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
>>>
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust code
should not require absolute speed

This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply. If you don't require absolute
speed, why are you using Rust?


On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq <
matthieu.monr...@gmail.com> wrote:

> I am not a fan of having wrap-around and non-wrap-around types, because
> whether you use wrap-around arithmetic or not is, in the end, an
> implementation detail, and having to switch types left and right whenever
> going from one mode to the other is going to be a lot of boilerplate.
>
> Instead, why not take the same road than swift and map +, -, * and / to
> non-wrap-around operators and declare new (more verbose) operators for the
> rare case where performance matters or wrap-around is the right semantics ?
>
> Even though Rust is a performance conscious language (since it aims at
> displacing C and C++), the 80/20 rule still applies and most of Rust code
> should not require absolute speed; so let's make it convenient to write
> safe code and prevent newcomers from shooting themselves in the foot by
> providing safety by default, and for those who profiled their applications
> or are writing hashing algorithms *also* provide the necessary escape
> hatches.
>
> This way we can have our cake and eat it too... or am I missing something ?
>
> -- Matthieu
>
>
>
> On Sun, Jun 22, 2014 at 5:45 AM, comex  wrote:
>
>> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay 
>> wrote:
>> >> Er... since when?  Many single-byte opcodes in x86-64 corresponding to
>> >> deprecated x86 instructions are currently undefined.
>> >
>> > http://ref.x86asm.net/coder64.html
>> >
>> > I don't see enough gaps here for the necessary instructions.
>>
>> You can see a significant number of invalid one-byte entries, 06, 07,
>> 0e, 1e, 1f, etc.  The simplest addition would just be to resurrect
>> INTO and make it efficient - assuming signed 64 and 32 bit integers
>> are good enough for most use cases.  Alternatively, it could be two
>> one-byte instructions to add an unsigned version (perhaps a waste of
>> precious slots) or a two-byte instruction which could perhaps allow
>> trapping on any condition.  Am I missing something?
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Benjamin Striegel]

> No one will use Rust if it's slow. If it uses checked arithmetic, it
> will be slow. There's nothing subjective about that.

This is the only argument that matters.

If we are slower than C++, Rust will not replace C++ and will have failed
at its goal of making the world a safer place. The world already has a glut
of safe and slow languages; if inefficiency were acceptable, then C++ would
have been replaced long ago.

In addition, bringing up hypothetical CPU architectures with support for
checked arithmetic is not relevant. Rust is a language designed for 2014,
not for 2024.

And if in 2024 we are all suddenly gifted with CPUs where checked
arithmetic is literally free and if this somehow causes Rust to be
"obsolete" (which seems unlikely in any case), then so be it. Rust is not
the last systems programming language that will ever be written.


On Sat, Jun 21, 2014 at 7:07 PM, Daniel Micay  wrote:

> On 21/06/14 06:54 PM, Jerry Morrison wrote:
> > I agree with Vadim that the world will inevitably become
> > security-conscious -- also safety-conscious. We will live to see it
> > unless such a bug causes nuclear war or power grid meltdown.
> >
> > When the sea change happens, Rust will either be (A)/ the attractive
> > choice for systems programming/ or (B) /obsolete/. Rust already has the
> > leading position in memory safety for systems programming, so it's lined
> > up to go.
>
> No one will use Rust if it's slow. If it uses checked arithmetic, it
> will be slow. There's nothing subjective about that.
>
> > The world desperately needs a C++ replacement for real-time,
> > safety-critical software before that ever-more-complicated language
> > causes big disasters. Rust is the only candidate around for that. (Or
> > maybe D, if its real-time threads can avoid GC pauses.) CACM's recent
> > /Mars Code/ article
> >  shows
> > the extremes that JPL has to do to program reliable space probes.
> > Smaller companies writing automobile engine control systems
> > <
> http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences
> >
> > and such will soon be looking for a more cost effective approach.
>
> Trapping on overflow doesn't turn the overflow into a non-bug. It
> prevents it from being exploited as a security vulnerability, but it
> would bring down a safety critical system.
>
> > Companies like Intel see so much existing C/C++ software getting by
> > without overflow safety and conclude it doesn't matter. Let's not let
> > their rear-view mirror thinking keep us stuck. Eventually customers will
> > demand better security whether there's a speed penalty or not.
> >
> > CPU designers could say they've given us so much instruction speed that
> > we can afford to spend some of it on overflow checking. Fair point. When
> > the software folks have demonstrated the broad need, Intel can speed it
> > up, whether by optimizing certain instruction sequences or adding new
> > instructions.
>
> Overflow checking means a branch on every integer arithmetic operation.
>
> It means every arithmetic operation is impure (unwinding) so LLVM won't
> be able to hoist stuff out of loops unless it proves that there's no
> overflow, which is rare. For example, this prevents it from hoisting a
> bounds check out of a loop by introducing a second kind of impure
> failure condition.
>
> It also prevents auto-vectorization, which is increasingly important. A
> language without good auto-vectorization is not going to be an
> interesting systems language down the road.
>
> > The Mill CPU architecture handles overflow nicely and promises much
> > higher performance, like extending DSP abilities into ordinary software
> > loops like strncpy(). Whether this one takes off or not is hard to say.
> > That little company could use a big partner.
>
> It has to exist before it can succeed or fail.
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On Copy = POD

[Benjamin Striegel]

> A user won't care if Arc and Rc are built-in or not.

They will definitely care, once they attempt to write their own pointer
types and find that they're second-class citizens compared to the types
that have been blessed by the compiler. There's little point in having a
powerful and extensible language if even simple types need hardcoded
compiler magic to function.


On Sat, Jun 21, 2014 at 7:42 AM, Paulo Sérgio Almeida 
wrote:

> Regarding the white-listing, I also find it weird, but should the user
> experience be worse just because Rc and Arc are implemented in Rust and so
> we should do nothing in the name of orthogonality? A user won't care if Arc
> and Rc are built-in or not.
>
> I may have passed the message that its only ugliness involved, and being
> lazy to type .clone(). But the point is uniformity and coherence of the
> pointers API, clarity, and ease of refactoring code. I am thinking of
> writing an RFC about cleaning up pointers. As of now there are some, in my
> opinion, needless non-uniformities in the use of pointers. I would like to
> have some properties:
>
> 1) Two programs that use pointers, identical except for pointer types and
> that both compile should produce semantically equivalent result (i.e., only
> differ in performance).
>
> The idea is that different pointer types would be chosen according to
> capabilities (is move enough or do I want to mutate something I own, pick
> Box; do I want to share intra-task, pick Rc or Gc; inter-task, pick Arc).
> If a program fragment is written using,  say Gc, and later I decide to
> switch to Rc, I should need only change the declaration site(s) and not
> have to go all-over and add .clone().
>
> (There are other things than Copy that need to be improved, like
> uniformity of auto-dereferencing and auto-borrowing. Fortunately I hope
> those to be not as controverse.)
>
> 2) Pointers should be transparent, and avoid confusion between methods of
> the pointer and methods of the referent.
>
> In particular, having non Box pointers Copy and avoiding pointer cloning,
> all .clone() in code would mean cloning the referent, being uniform with
> what happens with Box pointers. A clone should be something more rare and
> conscious. As of now, having mechanical .clone() in many places makes the
> "real" refent clones less obvious. An unintended referent clone may go more
> easily unnoticed.
>
> (Other aspects involve switching to UFCS style for pointer methods.)
>
> 3) Last use move optimisation should be applied for pointer types.
>
> This is not as essential, but as now, the compiler will know the last use
> place of a variable and use move instead of copy. All white-listed for Copy
> pointer-types must allow this optimisation. As we are talking about a
> controlled, to be approved set of types (i.e. Rc and Arc), and not general
> user-defined types, we can be sure that for all white-listed types this is
> so. Last use move optimisation would result in the same performance of code
> as now. Again, this is coherent with Box types, where the first use (by
> value) must be also the last use.
>
> Anyway, I would like to stress that much fewer pointer copies will exist
> in Rust given (auto-)borrowing. It is important to educate programers to
> always start by considering &T in function arguments, if they only need to
> use the T, and add more capabilities if needed. Something like &Rc if
> the function needs to use the T and occasionally copy the pointer, and only
> Rc if the normal case is copying the pointer.
>
> This is why I even argue that Arc should be Copy even considering the much
> more expensive copy. The important thing is programers knowing the cost,
> which will happen for the very few white-listed types, as opposed to
> allowing general user-defined copies for which the cost is not clear for
> the reader. A program using Arc should not Use Arc all-over, but only in a
> few places; after spawning, the proc will typically pass not the Arc but
> only &T to functions performing the work; this is unless those functions
> need to spawn further tasks but in this case, the Arc copies are need and
> in those places we would use .clone() anyway, resulting in the same
> performance.
>
>
>
> On 21 June 2014 10:10, Nick Cameron  wrote:
>
>> I guess I forgot that C++ ref counted pointers (pre-11) generally have a
>> move version of the type. Thanks for pointing that out.
>>
>> I agree it would be odd to copy that design (Rc/RcTemp) in a language
>> which has move semantics by default. I wonder if we could come up with
>> _some_ design that would be better than the current one. My reasoning is
>> that copy-with-increment is the (overwhelmingly) common case for
>> ref-counted pointers and so should be easier/prettier than the less common
>> case (moving). One could argue that the more efficient case (moving) should
>> be prettier and I think that is valid. I'm not sure how to square the two
>> arguments. I do think this deserves more thought than just 

Re: [rust-dev] On Copy = POD

[Benjamin Striegel]

> I don't think that is untenable, performance wise, after all it is what
everyone is currently doing in C++.

We have already made several decisions that will disadvantage us with
regard to C++. When we have the opportunity to do better, performance-wise,
than C++, we must seize it in order to maintain performance parity overall.


On Sat, Jun 21, 2014 at 2:06 AM, Nick Cameron  wrote:

> bstrie: you're right it is a trade off, but I don't agree that its not
> worth it. We're talking about non-atomic incrementing of an integer - that
> is pretty much the cheapest thing you can do on a processor (not free of
> course, since caching, etc., but still very cheap). I've programmed a lot
> in C++ with ref counted pointers and never had a problem remembering that
> there is a cost, and it makes using them pleasant. I found all the clone()s
> in Rust unpleasant, it really put me off using ref counting. The transition
> from using references to using Rc was particularly awful. Given that this
> is something C++ programmers coming to Rust will be used to using, I
> believe ergonomics is especially important.
>
> In this case I don't think we need to aim to be more 'bare metal' than
> C++. Transparent, ref counted pointers in C++ are popular and seem to work
> pretty well, although obviously not perfectly.
>
> zwarich: I haven't thought this through to a great extent, and I don't
> think here is the right place to plan the API. But, you ought to still have
> control over whether an Rc pointer is copied or referenced. If you have an
> Rc object and pass it to a function which takes an Rc, it is copied,
> if it takes a &Rc or a &T then it references (in the latter case with an
> autoderef-ref). If the function is parametric over U and takes a &U, then
> we instantiate U with either Rc or T (in either case it would be passed
> by ref without an increment, deciding which is not changed by having a copy
> constructor). If the function takes a U literal, then U must be
> instantiated with Rc. So, you still get to control whether you reference
> with an increment or not.
>
> I think if Rc is copy, then it is always copied. I would not expect it to
> ever move. I don't think that is untenable, performance wise, after all it
> is what everyone is currently doing in C++. I agree the second option seems
> unpredictable and thus less pleasant.
>
> Cheers, Nick
>
>
> On Sat, Jun 21, 2014 at 4:05 PM, Cameron Zwarich 
> wrote:
>
>> I sort of like being forced to use .clone() to clone a ref-counted value,
>> since it makes the memory accesses and increment more explicit and forces
>> you to think which functions actually need to take an Rc and which
>> functions can simply take an &.
>>
>> Also, if Rc becomes implicitly copyable, then would it be copied rather
>> than moved on every use, or would you move it on the last use? The former
>> seems untenable for performance reasons, since removing unnecessary
>> ref-count operations is important for performance. The latter seems
>> unpredictable, since adding a second use of a value in a function would
>> mean that new code is implicitly executed wherever the first use is.
>>
>> Cameron
>>
>> On Jun 20, 2014, at 8:49 PM, Nick Cameron  wrote:
>>
>> I think having copy constructors is the only way to get rid of `.clone()`
>> all over the place when using` Rc`. That, to me, seems very important (in
>> making smart pointers first class citizens of Rust, without this, I would
>> rather go back to having @-pointers). The trouble is, I see incrementing a
>> ref count as the upper bound on the work that should be done in a copy
>> constructor and I see no way to enforce that.
>>
>> So, I guess +1 to spirit of the OP, but no solid proposal for how to do
>> it.
>>
>>
>> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel <
>> ben.strie...@gmail.com> wrote:
>>
>>> I'm not a fan of the idea of blessing certain types with a
>>> compiler-defined whitelist. And if the choice is then between ugly code and
>>> copy constructors, I'll take ugly code over surprising code.
>>>
>>>
>>> On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton 
>>> wrote:
>>>
>>>> On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]
>>>>
>>>>  Currently being Copy equates with being Pod. The more time passes and
>>>>> the more code examples I see, it is amazing the amount of ugliness that
>>>>> it causes. I wonder if there is a way out.
>>>>>
>>>>
>>>> Part of the problem is that a lot o

Re: [rust-dev] On Copy = POD

[Benjamin Striegel]

> I think having copy constructors is the only way to get rid of `.clone()`
all over the place when using` Rc`.

I find making `.clone()` explicit to be a valuable feature, and I bet I'm
not the only one. Its absence guarantees that the pointer is being moved
and no refcount is being bumped.

It's one thing if the inclusion of copy constructors allows code to be more
generic. But muddying program behavior just to make the source code
prettier is a poor tradeoff for a systems language.


On Fri, Jun 20, 2014 at 11:49 PM, Nick Cameron  wrote:

> I think having copy constructors is the only way to get rid of `.clone()`
> all over the place when using` Rc`. That, to me, seems very important (in
> making smart pointers first class citizens of Rust, without this, I would
> rather go back to having @-pointers). The trouble is, I see incrementing a
> ref count as the upper bound on the work that should be done in a copy
> constructor and I see no way to enforce that.
>
> So, I guess +1 to spirit of the OP, but no solid proposal for how to do it.
>
>
> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel  > wrote:
>
>> I'm not a fan of the idea of blessing certain types with a
>> compiler-defined whitelist. And if the choice is then between ugly code and
>> copy constructors, I'll take ugly code over surprising code.
>>
>>
>> On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton 
>> wrote:
>>
>>> On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]
>>>
>>>  Currently being Copy equates with being Pod. The more time passes and
>>>> the more code examples I see, it is amazing the amount of ugliness that
>>>> it causes. I wonder if there is a way out.
>>>>
>>>
>>> Part of the problem is that a lot of library code assumes that Copy
>>> types can be copied by just moving bytes around. Having copy constructors
>>> would mean that this simplifying assumption would have to change. It's
>>> doable, I suppose, but having copy constructors would have a significant
>>> downside.
>>>
>>> Patrick
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On Copy = POD

[Benjamin Striegel]

I'm not a fan of the idea of blessing certain types with a compiler-defined
whitelist. And if the choice is then between ugly code and copy
constructors, I'll take ugly code over surprising code.


On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton 
wrote:

> On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]
>
>  Currently being Copy equates with being Pod. The more time passes and
>> the more code examples I see, it is amazing the amount of ugliness that
>> it causes. I wonder if there is a way out.
>>
>
> Part of the problem is that a lot of library code assumes that Copy types
> can be copied by just moving bytes around. Having copy constructors would
> mean that this simplifying assumption would have to change. It's doable, I
> suppose, but having copy constructors would have a significant downside.
>
> Patrick
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Why are generic integers not usable as floats?

[Benjamin Striegel]

I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
wouldn't want `let x: int = 1.0;` to be valid.


On Thu, Jun 19, 2014 at 7:02 PM, Matthew McPherrin 
wrote:

> This came up on IRC today, and it was something I've wondered in the past
> but nobody had an immediately good answer either way.
>
> I think it's fairly inconsistent that these two code samples aren't
> equivalent:
>
> let a = 1f32;
>   let b: f32 = 1;
>
> It's fairly annoying in my opinion to have to occasionally add a .0 after
> floating point literals.
>
> Especially since we're getting rid of integer fallback in RFC 30, I think
> this issue ought to be thought about.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] iOS cross compilation

[Benjamin Striegel]

This is great! But how are we testing this? Do we have an iOS buildbot? Or
is it liable to break at any moment?


On Mon, Jun 16, 2014 at 2:04 PM, Alex Crichton  wrote:

> Nice job Valerii! This is all thanks to the awesome work you've been
> doing wrangling compiler-rt and the standard libraries. I'm excited to
> see what new applications Rust can serve on iOS!
>
> On Mon, Jun 16, 2014 at 9:19 AM, Valerii Hiora 
> wrote:
> > Hi,
> >
> >   So finally Rust can cross-compile for iOS (armv7 only for now). BTW,
> > it also means that Rust now can be used both for iOS and Android
> > low-level development.
> >
> >   Short instructions are available here:
> >   https://github.com/mozilla/rust/wiki/Doc-building-for-ios
> >
> >   Unfortunately LLVM patch for supporting segmented stacks on armv7 was
> > declined by Apple (it used kind of private API) and therefore there is
> > no stack protection at all.
> >
> >   It still could be enabled by compiling with a patched LLVM (I can
> > provide a patch and instructions if needed).
> >
> >   Everything else should "just work" but let me know if you have any
> > problem.
> >
> > --
> >
> >   Valerii
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] &self/&mut self in traits considered harmful(?)

[Benjamin Striegel]

> The manner in which the expression accomplishes this task is an
implementation detail.

You're welcome to draft a proposal if you think that you have an idea to
make this possible. Though all of the solutions that I can envision require
abandoning the idea of operators-as-traits and introducing a whole lot of
magic in their place.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] how is Rust bootstrapped?

[Benjamin Striegel]

This does raise a good question though: post-1.0, will we continue the
current procedure of snapshotting whenever we feel like it, or will we
restrict snapshots to stable releases, as Go plans to do?

https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true

"The rule we plan to adopt is that the Go 1.3 compiler must compile using
Go 1.2, Go 1.4 must compile using Go 1.3, and so on."




On Mon, Jun 9, 2014 at 1:00 PM, Brian Anderson 
wrote:

> This is an interesting idea, but I don't see it happening for a long time
> if ever:
>
> * The current process is working fine
> * rustc depends on many of the standard libraries, so restricting rustc
> means figuring out how to stick to a fixed subset of those libraries
> * It's a lot of work to make the bootstrap process even *more* complicated
> * For some minor benefits
>
>
> On 06/09/2014 06:34 AM, James Cassidy wrote:
>
>> On Mon, Jun 09, 2014 at 12:55:00PM +, Sanghyeon Seo wrote:
>>
>>> Do you plan to create a cleaner full-bootstrap process?
 By "cleaner" I mean dividing stage-0 to more [sub-]stages,
 which would be well-defined and documented in terms of
 the set of language features it implements. Currently these
 sub-stages are defined by a team member's mood to instruct
 the build-bots to make a snapshot. This kind of bootstrap
 seems to be a black-box.

>>> As I understand, there is no plan to do this. "Bootstrap" you are talking
>>> about is purely theoretical, and I don't think anyone actually performed
>>> it.
>>> In practice, Rust is bootstrapped from the downloaded binary.
>>>
>>>  I understand you do not spend resource on such tasks before 1.0,
 but do you think this is a legitimate|sensible request at all?
 Would it be worth the work?

>>> Personally, I don't see any value in doing this work. C compilers are
>>> bootstrapped from C compiler binaries. Analogously, the Rust compiler
>>> is bootstrapped from the Rust compiler binary.
>>>
>>> Trying to bootstrap from rustboot would be akin to trying to bootstrap
>>> GCC from last1120c (the oldest C compiler with surviving source code).
>>> An interesting feat of computer archaeology, but not really useful for
>>> anything.
>>>
>>>  I think he was more referring to what language features will be allowed
>> in the
>> rust compiler itself where earlier stages would be more restricted so
>> they can
>> be compiled with older rust compilers, for example hopefully rustc 2.0
>> can be
>> compiled by rustc 1.0.  Then later stages could use more features since
>> it will
>> be compiled with the more up to date earlier stage.
>>
>> Currently what features can be used in the compiler itself are just
>> limited to
>> whenever someone decides to compiler a newer stage0 compiler.
>>
>>
>> -- Jim
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Taking ownership of the datetime library

[Benjamin Striegel]

This is quite an undertaking. Thanks for taking the initiative!


On Sun, Jun 8, 2014 at 4:10 AM, Dietrich Epp  wrote:

> Unless there’s a good objection I’m taking ownership of the datetime
> library, as luisbg’s efforts seem to be abandoned.  I’ve read the wiki, the
> last mailing list discussion, and I’ve familiarized myself with JSR 310,
> Joda Time, Noda Time, the C++ proposal, and others.
>
> Here is the repository: https://github.com/depp/datetime-rs
>
> If you want to do any bikeshedding, please review the /doc folder, and
> feel free to edit the wiki or post issues or pull requests through GitHub.
>  Code review is also welcome, although there is only one module implemented
> yet.
>
> —Dietrich
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Confused about the precedence of 'as' operator

[Benjamin Striegel]

The manual also says that `as` somehow has a lower precedence than `*` and
yet a higher precedence than `+`, which would be hilarious madness. Don't
trust the manual.


On Fri, May 30, 2014 at 11:02 AM, Tommi  wrote:

> The manual says that the precedence of `as` operator is lower than that of
> the binary `*` operator. Thus I would not expect the following to compile
> (but it does):
>
> let a: u16 = 1;
> let b: u32 = 2;
>
> let r = a * b as u16;
>
>
> Since multiplication is supposed to have precedence over casting, I would
> expect the last line to be equivalent to:
>
> let r = (a * b) as u16;
>
> ...which doesn't compile because `a` and `b` have different types.
>
>
> Here the compiler clearly first converts `b` to u16 and then multiplies
> `a` with the result of that conversion:
>
> let r = a * b as u16;
>
> ...but that should happen only if the `as` operator has a higher
> precedence than the binary `*` operator.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] The meaning of 'box ref foo' ?

[Benjamin Striegel]

What you're overlooking is that patterns are used for more than just
`match` expressions. They can also be used in both assignment statements
and in function/closure signatures. For example, note that `x` and `y` are
the same type in the following program:

fn main() {
let ref x = 3;
let y = &3;
foo(x);
foo(y);
}

fn foo(x: &int) {
println!("{:i}", *x);
}


Removing the `ref` keyword and making patterns reference by default would
make `let x = 3;` declare a reference to an integer. Then you'd need a new
keyword to express when you don't want this, and you're back at square one.


On Fri, May 30, 2014 at 9:56 AM, Emmanuel Surleau <
emmanuel.surl...@gmail.com> wrote:

> I think the 'ref' keyword removal is a very good idea. It has bitten
> me several times, and the idea that pattern matching something
> essentially performs a side effect (moving the value) leaves me
> uncomfortable.
>
> Cheers,
>
> Emm
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

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
wrote:

> > but people will still end up calling the
>
> *exact same method*
> ...Except when they actually intended to call any other method of
> determining the length of a string, but were stymied by poor naming and
> inadequate understanding. But if your argument is "people will only call
> the method that tells them how many bytes are in the string when they want
> to know how many bytes are in the string", then yes, I should hope so.
> Let's help them understand which method is appropriate.
>
> 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
> coaster that one year on the first day of summer vacation when the string's
> parents took the string to that amusement park and the weather said that it
> was going to rain so there were almost no crowds that day but then it
> didn't rain and all the rides were open with absolutely no lines whatsoever.
>
> As Daniel has mentioned above, if you want to perform byte operations on a
> String without being forced to type "byte" every time, then call
> .as_bytes() on it once and run wild. Though at this point I think at this
> we're just arguing in circles, and will have to simply agree to disagree.
>
>
> On Wed, May 28, 2014 at 7:00 PM, Kevin Ballard  wrote:
>
>> On May 28, 2014, at 3:24 PM, Huon Wilson  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 disagree completely.
>>
>> Path does not implement Show, because of ToStr (and just generally,
>> because Show can be used to convert to a string representation). This isn't
>> a problem for most types, but paths are special in that a lot of people
>> think that they can be represented with strings, and therefore will try to
>> do that. Because Path does not implement Show it's difficult to incorrectly
>> convert it to a string (it exposes methods for getting an Option<&str>
>> which is the correct way to do it).
>>
>> This is about preventing the user from doing something incorrectly, and
>> forcing them to use the correct method.
>>
>> Meanwhile, renaming .len() to .byte_len() doesn't actually prevent
>> anything. It will just confuse people (and cause a lot of unnecessary
>> typing of "byte_"), but people will still end up calling the *exact same
>> method*. They did the same operation, they just got annoyed in the
>> process.
>>
>> It's important to note here that in most cases .len() actually is the
>> correct method to call. This has been discussed before, but basically,
>> string manipulation needs to use byte indexes (well, code unit indexes) to
>> be at all efficient, and that's why the character-based methods have
>> special names. This means that the byte-based methods are the ones we're
>> expecting people to use. Renaming them doesn't change that fact.
>>
>> If someone doesn't give any thought to non-ASCII text, putting "byte" in
>> the method name isn't going to change that. And if they do give thought to
>> non-ASCII text, leaving "byte" out of the name doesn't cause any issues.
>>
>> Don't forget that renaming .byte_len() only makes sense if we rename
>> .slice()/.slice_from()/.slice_to() to
>> .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being
>> extremely verbose, these methods imply that they return a "byte slice", or
>> a &[u8].
>>
>> -Kevin
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

> but people will still end up calling the

*exact same method*
...Except when they actually intended to call any other method of
determining the length of a string, but were stymied by poor naming and
inadequate understanding. But if your argument is "people will only call
the method that tells them how many bytes are in the string when they want
to know how many bytes are in the string", then yes, I should hope so.
Let's help them understand which method is appropriate.

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
coaster that one year on the first day of summer vacation when the string's
parents took the string to that amusement park and the weather said that it
was going to rain so there were almost no crowds that day but then it
didn't rain and all the rides were open with absolutely no lines whatsoever.

As Daniel has mentioned above, if you want to perform byte operations on a
String without being forced to type "byte" every time, then call
.as_bytes() on it once and run wild. Though at this point I think at this
we're just arguing in circles, and will have to simply agree to disagree.


On Wed, May 28, 2014 at 7:00 PM, Kevin Ballard  wrote:

> On May 28, 2014, at 3:24 PM, Huon Wilson  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 disagree completely.
>
> Path does not implement Show, because of ToStr (and just generally,
> because Show can be used to convert to a string representation). This isn't
> a problem for most types, but paths are special in that a lot of people
> think that they can be represented with strings, and therefore will try to
> do that. Because Path does not implement Show it's difficult to incorrectly
> convert it to a string (it exposes methods for getting an Option<&str>
> which is the correct way to do it).
>
> This is about preventing the user from doing something incorrectly, and
> forcing them to use the correct method.
>
> Meanwhile, renaming .len() to .byte_len() doesn't actually prevent
> anything. It will just confuse people (and cause a lot of unnecessary
> typing of "byte_"), but people will still end up calling the *exact same
> method*. They did the same operation, they just got annoyed in the
> process.
>
> It's important to note here that in most cases .len() actually is the
> correct method to call. This has been discussed before, but basically,
> string manipulation needs to use byte indexes (well, code unit indexes) to
> be at all efficient, and that's why the character-based methods have
> special names. This means that the byte-based methods are the ones we're
> expecting people to use. Renaming them doesn't change that fact.
>
> If someone doesn't give any thought to non-ASCII text, putting "byte" in
> the method name isn't going to change that. And if they do give thought to
> non-ASCII text, leaving "byte" out of the name doesn't cause any issues.
>
> Don't forget that renaming .byte_len() only makes sense if we rename
> .slice()/.slice_from()/.slice_to() to
> .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being
> extremely verbose, these methods imply that they return a "byte slice", or
> a &[u8].
>
> -Kevin
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

> 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 prefer to think of them as "more explicit, clear, self-documenting
names". Code readers will also benefit from the reduced ambiguity, even if
the code authors are burdened with typing an onerous five additional
keystrokes.


On Wed, May 28, 2014 at 4:38 PM, Kevin Ballard  wrote:

> On May 28, 2014, at 1:26 PM, Benjamin Striegel 
> 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 code points, code units,
> and grapheme clusters. If we have a single unadorned `len` function, that
> implies the existence of a "default" length to a UTF-8 string, which is a
> lie. It also *fails* to suggest the existence of alternative measures of
> length of a UTF-8 string. Finally, the choice of byte length as the default
> length metric encourages the horrid status quo, which is the perpetuation
> of code that is tested and works in ASCII environments but barfs as soon as
> anyone from a sufficiently-foreign culture tries to use it. Dedicating
> ourselves to Unicode support does us no good if the remainder of our API
> encourages the depressingly-typical ASCII-ism that pervades nearly every
> other language.
>
>
> Do you honestly believe that calling it .byte_len() will do anything
> besides confusing anyone who expects .len() to work, and resulting in code
> that looks any different than just using .byte_len() everywhere people use
> .len() today?
>
> Forcing more verbose, annoying, unconventional names on people won't
> actually change how they process strings. It will just confuse and annoy
> them.
>
> -Kevin
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

> 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 implies understanding the difference between code points, code units,
and grapheme clusters. If we have a single unadorned `len` function, that
implies the existence of a "default" length to a UTF-8 string, which is a
lie. It also *fails* to suggest the existence of alternative measures of
length of a UTF-8 string. Finally, the choice of byte length as the default
length metric encourages the horrid status quo, which is the perpetuation
of code that is tested and works in ASCII environments but barfs as soon as
anyone from a sufficiently-foreign culture tries to use it. Dedicating
ourselves to Unicode support does us no good if the remainder of our API
encourages the depressingly-typical ASCII-ism that pervades nearly every
other language.


On Wed, May 28, 2014 at 3:48 PM, Kevin Ballard  wrote:

> On May 28, 2014, at 11:55 AM, Benjamin Striegel 
> 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 opinionated by enforcing UTF-8 in our
> strings. This is an extension of that break with tradition.
>
>
> There's no clear tradition regarding strings. Some languages treat strings
> as just blobs of binary data with no associated encoding (and obviously,
> operate on bytes). Some languages use an associated encoding with every
> string, but those are pretty rare. Some languages, such as JavaScript and
> Obj-C, use UCS-2 (well, Obj-C tries to be UTF-16 but all of its accessors
> that operate on characters actually operate on UTF-16 code units, which is
> effectively equivalent to UCS-2).
>
> > Today we only need to teach the simple concept that strings are utf-8
> encoded
>
> History has shown that understanding Unicode is not a simple concept.
> Asking for the "length" of a Unicode string is not a well-formed question,
> and we must express this in our API. I also don't agree with accessor
> functions that work on code units without warning, and for this reason I
> strongly disagree with supporting the [] operator on strings.
>
>
> Unicode is not a simple concept. UTF-8 on the other hand is a pretty
> simple concept. And string accessors that operate at the code unit level
> are *very* common (in fact, I can't think of a single language that
> doesn't operate on code units by default[1][2]). Pretty much the only odd
> part about Rust's behavior here is that the slicing methods (with the
> exception of slice_chars()) will fail if the byte index isn't on a
> character boundary, but that's a natural extension of the fact that Rust
> strings are guaranteed to be valid utf-8. And it's unrelated to the naming
> (even if it were called .byte_slice() it would still fail with the same
> input; and honestly, .byte_slice() looks like it will return a &[u8]).
>
> Of course, we haven't mentioned .byte_slice() before, but if you're going
> to rename .len() to .byte_len() you're going to have to add .byte_ prefixes
> to all of the other methods that take byte indexes.
>
> In any case, the core idea here is that .len() returns "the length" of the
> string. And "the length" is the number of code units. This matches the
> behavior of other languages.
>
> -Kevin
>
> [1]: Even Haskell can be said to operate on code units, as its built-in
> string is a linked list of UTF-32 characters, which means the code unit is
> the character. Although I don't know offhand how Data.Text or
> Data.ByteString work.
>
> [2]: Python 2.7 operates on bytes, but I just did some poking around in
> Python3 and it seems to use characters for length and indexing. I don't
> know what the internal representation of a Python3 string is, though, so I
> don't know if they're using O(n) operations, or if they're using
> UTF-16/UTF-32 internally as necessary.
>
> On Wed, May 28, 2014 at 2:42 PM, Kevin Ballard  wrote:
>
>> 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 the thing
>> .byte_len() over merely documenting that .len() is in code units.
>>

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

> 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 tradition.

> Today we only need to teach the simple concept that strings are utf-8
encoded

History has shown that understanding Unicode is not a simple concept.
Asking for the "length" of a Unicode string is not a well-formed question,
and we must express this in our API. I also don't agree with accessor
functions that work on code units without warning, and for this reason I
strongly disagree with supporting the [] operator on strings.


On Wed, May 28, 2014 at 2:42 PM, Kevin Ballard  wrote:

> 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 the thing
> .byte_len() over merely documenting that .len() is in code units.
> Everything else that doesn't explicitly say "char" on strings is in code
> units too, so it's sensible that .len() is too. But having strings that
> don't have an inherent "length" is confusing to anyone who hasn't already
> memorized this difference.
>
> Today we only need to teach the simple concept that strings are utf-8
> encoded, and the corresponding notion that all of the accessor methods on
> strings (including indexing using []) use code units unless they specify
> otherwise (e.g. unless they contain the word "char").
>
> -Kevin
>
> On May 28, 2014, at 10:54 AM, Benjamin Striegel 
> wrote:
>
> > 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 1:12 PM, Kevin Ballard  wrote:
>
>> 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
>> functions).
>>
>> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to
>> be the number of UTF-8 code units. Which happens to be the number of bytes.
>>
>> -Kevin
>>
>> On May 28, 2014, at 7: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.
>>
>>
>> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote:
>>
>>> On 28/05/2014 10:46, Aravinda VK wrote:
>>>
>>>> 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 length to grapheme
>>>> cluster length for Kannada language.
>>>>
>>>
>>> Be careful, JavaScript’s String.length counts UCS-2 code units, not code
>>> points…
>>>
>>>
>>> --
>>> Simon Sapin
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

> 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 1:12 PM, Kevin Ballard  wrote:

> 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
> functions).
>
> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be
> the number of UTF-8 code units. Which happens to be the number of bytes.
>
> -Kevin
>
> On May 28, 2014, at 7: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.
>
>
> On Wed, May 28, 2014 at 5:55 AM, Simon Sapin  wrote:
>
>> On 28/05/2014 10:46, Aravinda VK wrote:
>>
>>> 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 length to grapheme
>>> cluster length for Kannada language.
>>>
>>
>> Be careful, JavaScript’s String.length counts UCS-2 code units, not code
>> points…
>>
>>
>> --
>> Simon Sapin
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Benjamin Striegel]

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  wrote:

> On 28/05/2014 10:46, Aravinda VK wrote:
>
>> 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 length to grapheme
>> cluster length for Kannada language.
>>
>
> Be careful, JavaScript’s String.length counts UCS-2 code units, not code
> points…
>
>
> --
> Simon Sapin
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] StrBuf and regular expressions

[Benjamin Striegel]

> 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 little discussion regarding it.


On Tue, May 27, 2014 at 10:17 PM, Kevin Ballard  wrote:

> On May 27, 2014, at 1:55 PM, Benjamin Striegel 
> wrote:
>
> What I was specifically curious about is why you seem to be against the
> usage of the `Str` trait as a bound on the argument to the `captures`
> method.
>
>
> It adds unnecessary complexity, bloats the crate metadata with the
> function AST, and complicates the type signature, with no real benefit. The
> only thing that taking `` for an `arg: S` argument does is allowing
> a String to be passed without calling .as_slice(). But the 
> solution moves the String into the function, rather than slicing it, which
> means the calling function gives up ownership of the String. This is rarely
> desired, and is likely to be confusing.
>
> We're also almost certainly going to implement Deref on String
> post-DST, which means slicing a String is a simple as &*foo. 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).
>
> -Kevin
>
> On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard  wrote:
>
>> On May 27, 2014, at 6:05 AM, Benjamin Striegel 
>> wrote:
>>
>>  > The use of taking  is for taking things like &[S], where you
>> want to take both &str and String (such as in the other post about
>> getops()).
>>
>> I wouldn't be bothered with leaving the API as-is, but I don't understand
>> where this guideline is coming from. Can you elaborate?
>>
>>
>> I don't know if there's any authoritative source for this, but it's been
>> suggested in the past for other APIs. The basic issue is that &[String]
>> cannot be freely converted to &[&str]; you need to allocate a new Vec for
>> that. So if you have a &[String] and try to call an API that takes a
>> &[&str] then you're doing extra work just to satisfy the type system. But
>> the function in question doesn't actually need &[&str], it just needs a
>> slice of things it can convert to &str. So if it takes  &[S] then
>> you can hand it your &[String] without conversion, or you can hand it a
>> &[&str], and it will work with both.
>>
>> This doesn't necessarily mean you need to use  &[S] everywhere.
>> But it's a nice thing to do if you think about it.
>>
>> -Kevin
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] StrBuf and regular expressions

[Benjamin Striegel]

What I was specifically curious about is why you seem to be against the
usage of the `Str` trait as a bound on the argument to the `captures`
method.


On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard  wrote:

> On May 27, 2014, at 6:05 AM, Benjamin Striegel 
> wrote:
>
>  > The use of taking  is for taking things like &[S], where you
> want to take both &str and String (such as in the other post about
> getops()).
>
> I wouldn't be bothered with leaving the API as-is, but I don't understand
> where this guideline is coming from. Can you elaborate?
>
>
> I don't know if there's any authoritative source for this, but it's been
> suggested in the past for other APIs. The basic issue is that &[String]
> cannot be freely converted to &[&str]; you need to allocate a new Vec for
> that. So if you have a &[String] and try to call an API that takes a
> &[&str] then you're doing extra work just to satisfy the type system. But
> the function in question doesn't actually need &[&str], it just needs a
> slice of things it can convert to &str. So if it takes  &[S] then
> you can hand it your &[String] without conversion, or you can hand it a
> &[&str], and it will work with both.
>
> This doesn't necessarily mean you need to use  &[S] everywhere.
> But it's a nice thing to do if you think about it.
>
> -Kevin
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] StrBuf and regular expressions

[Benjamin Striegel]

> The use of taking  is for taking things like &[S], where you want
to take both &str and String (such as in the other post about getops()).

I wouldn't be bothered with leaving the API as-is, but I don't understand
where this guideline is coming from. Can you elaborate?


On Mon, May 26, 2014 at 5:55 PM, Kevin Ballard  wrote:

> captures() should not take . That's unnecessary, it should just
> take &str as it does now. The use of taking  is for taking things
> like &[S], where you want to take both &str and String (such as in the
> other post about getops()).
>
> For the time being, the answer is to use .as_slice() explicitly. The
> proposed Deref implementation post-DST has been talked about, and seems
> reasonably likely (though no decision has been made about it).
>
> The remaining bit to this is that, AFAIK, we don't auto-deref function
> arguments. We had auto-borrow of ~str into &str, but that doesn't apply to
> String. It has been suggested that maybe we should auto-deref+autoref
> function arguments such that String could then automatically coerce into
> &str, but this has had very little discussion so far.
>
> My suggestion is to wait until we have DST, then file an RFC suggesting
> the autoderef behavior for function arguments (and suggesting Deref on
> String if we haven't already done that).
>
> -Kevin
>
> On May 26, 2014, at 12:10 PM, Benjamin Striegel 
> wrote:
>
> I don't think any of these will be necessary.
>
> We already have a trait called `Str` (which is a bad name, btw) in the
> std::str module. This trait has exactly one method: `as_slice`. This trait
> is already implemented on both `&str` and `StrBuf` (the former in std::str,
> the latter in std::strbuf). All that would need to be done is to make the
> `captures` method generic on any type that implements `Str`, and then have
> it call the `as_slice` method before doing exactly what it does today. This
> extra operation would compile to a no-op for slices, and the usual cheap
> slice operation for heap-allocated strings. Then you would be able to call
> `re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`.
>
>
> On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov  wrote:
>
>> Perhaps Rust should provide something like BorrowAsStr trait allowing
>> to convert automatically to &str. &* is just too ugly...
>>
>> On 26 May 2014 08:58, Vladimir Matveev  wrote:
>> >> My suspicion is that the automatic conversion will come back at some
>> >> point, but I'm not sure.
>> >
>> > I think it will be possible to make `String` implement `Deref`
>> > when DST land. Then it will be possible to convert from `String` to
>> > `&str` using explicit reborrowing:
>> >
>> > let sgf_slice = &*sgf;
>> >
>> > I'm not sure this will be fully automatic when `String` is an
>> > arbitrary actual argument to arbitrary function, however.
>> >
>> > 2014-05-26 10:36 GMT+04:00 Andrew Gallant :
>> >> Try using `self.sgf.as_slice()` instead.
>> >>
>> >> The change is necessary, AFAIK, because `~str` would automatically be
>> >> converted to a borrowed reference without having to explicitly call the
>> >> `as_slice` method. This doesn't happen for the StrBuf (and what is now
>> >> String, I think) type.
>> >>
>> >> My suspicion is that the automatic conversion will come back at some
>> >> point, but I'm not sure.
>> >>
>> >> - Andrew
>> >>
>> >>
>> >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner 
>> wrote:
>> >>> Hello there,
>> >>>
>> >>> I just updated the compiler (I use the git master branch) and now
>> when I
>> >>> read in a file I get a StrBuf instead of a ~str. That is easy enough
>> to
>> >>> change, but how do I use regular expressions now? I have the
>> following in my
>> >>> code:
>> >>>
>> >>> let re = regex!(r"SZ\[(\d+)\]");
>> >>> let captures = re.captures(self.sgf).unwrap();
>> >>>
>> >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do
>> I have
>> >>> just a Rust compiler that is somewhere in between (i.e. not
>> everything has
>> >>> been changed to StrBuf) or is this intentional? And if so, what's the
>> best
>> >>> way to use regular expressions now?
>> >>>
>> >>> Urb

Re: [rust-dev] Array of heap allocated strings for opts_present?

[Benjamin Striegel]

I'm not familiar with the getopts module, but on the surface that behavior
sounds wrong to me.

As for the verbosity of the repeated `to_owned` calls, this sounds like the
perfect application for macros:

#![feature(macro_rules)]

macro_rules! owned(
($($e:expr),*) => ([$($e.to_owned()),*])
)

fn main() {
let x = owned!["b", "c", "d"];
}


On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh wrote:

> Why does getopts::Matches::opts_present() take an array of heap allocated
> strings? Unless I'm missing something, it doesn't seem like it needs to:
> https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302
>
> Currently, my code to use it looks like this:
>
> if matches.opts_present(["b".to_owned(), "x".to_owned(), "s".to_owned(),
> "w".to_owned()]) { /* */ }
>
> 1. Should the function be converted to take a list of borrowed strings?
> 2. Regardless of what this function should take as an argument, is the way
> I'm constructing a list of StrBufs the correct way to do it? It seems a bit
> verbose.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] StrBuf and regular expressions

[Benjamin Striegel]

I don't think any of these will be necessary.

We already have a trait called `Str` (which is a bad name, btw) in the
std::str module. This trait has exactly one method: `as_slice`. This trait
is already implemented on both `&str` and `StrBuf` (the former in std::str,
the latter in std::strbuf). All that would need to be done is to make the
`captures` method generic on any type that implements `Str`, and then have
it call the `as_slice` method before doing exactly what it does today. This
extra operation would compile to a no-op for slices, and the usual cheap
slice operation for heap-allocated strings. Then you would be able to call
`re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`.


On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov  wrote:

> Perhaps Rust should provide something like BorrowAsStr trait allowing
> to convert automatically to &str. &* is just too ugly...
>
> On 26 May 2014 08:58, Vladimir Matveev  wrote:
> >> My suspicion is that the automatic conversion will come back at some
> >> point, but I'm not sure.
> >
> > I think it will be possible to make `String` implement `Deref`
> > when DST land. Then it will be possible to convert from `String` to
> > `&str` using explicit reborrowing:
> >
> > let sgf_slice = &*sgf;
> >
> > I'm not sure this will be fully automatic when `String` is an
> > arbitrary actual argument to arbitrary function, however.
> >
> > 2014-05-26 10:36 GMT+04:00 Andrew Gallant :
> >> Try using `self.sgf.as_slice()` instead.
> >>
> >> The change is necessary, AFAIK, because `~str` would automatically be
> >> converted to a borrowed reference without having to explicitly call the
> >> `as_slice` method. This doesn't happen for the StrBuf (and what is now
> >> String, I think) type.
> >>
> >> My suspicion is that the automatic conversion will come back at some
> >> point, but I'm not sure.
> >>
> >> - Andrew
> >>
> >>
> >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner 
> wrote:
> >>> Hello there,
> >>>
> >>> I just updated the compiler (I use the git master branch) and now when
> I
> >>> read in a file I get a StrBuf instead of a ~str. That is easy enough to
> >>> change, but how do I use regular expressions now? I have the following
> in my
> >>> code:
> >>>
> >>> let re = regex!(r"SZ\[(\d+)\]");
> >>> let captures = re.captures(self.sgf).unwrap();
> >>>
> >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do
> I have
> >>> just a Rust compiler that is somewhere in between (i.e. not everything
> has
> >>> been changed to StrBuf) or is this intentional? And if so, what's the
> best
> >>> way to use regular expressions now?
> >>>
> >>> Urban
> >>> --
> >>> Freelancer
> >>>
> >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects
> >>>
> >>> More at http://urbanhafner.com
> >>>
> >>> ___
> >>> Rust-dev mailing list
> >>> Rust-dev@mozilla.org
> >>> https://mail.mozilla.org/listinfo/rust-dev
> >>>
> >> ___
> >> Rust-dev mailing list
> >> Rust-dev@mozilla.org
> >> https://mail.mozilla.org/listinfo/rust-dev
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback

[Benjamin Striegel]

On Fri, May 23, 2014 at 12:12 AM, Patrick Walton wrote:

>  You can use "extern "Rust" fn" (or ||:'static) to achieve something like
> C++03 member function pointers without the lifetimes. Attacking Rust
> without asking first how to do this is unappreciated.
>

I think that characterizing this as an "attack" is in bad faith. This is a
very impressive and insightful post. Alexander is a member of our primary
demographic, and it is immensely valuable to get real-world feedback on how
C++ users will receive the language when employing it for non-trivial
projects.

If there is a misunderstanding over some of Rust's features, then it is a
documentation deficiency that needs to be addressed. The fact that
Alexander took the effort to post this here at all shows that he wants to
understand the language, not to bash it. If only every blogger was so
considerate!

So thank you, Alexander. I hope that you found Rust enjoyable despite its
current rough edges! I'd love it if you kept an eye on the language as it
develops, and I'd be delighted to read a follow-up post incorporating the
feedback from here and from reddit.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New on Rust/Servo

[Benjamin Striegel]

Welcome!

The easiest way to install the compiler will be to download the binaries
here:

http://www.rust-lang.org/install.html .

Prefer the "Nightly" binaries and not the 0.10 binaries. Unzip the download
and run the "install.sh" script inside.

If you're using Linux, you can do the above steps using the following
command:

wget
http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz&&;
tar xvf rust-nightly-x86_64-unknown-linux-gnu.tar.gz && cd
rust-nightly-x86_64-unknown-linux-gnu/ && sudo ./install.sh

This will give you a copy of the compiler to play around with. Test it out
like this:

rustc --help

Compile and run the "hello world" program:

echo 'fn main() { println!("Hello, Ricardo!"); }' | rustc -o hello '-'
&& ./hello

Compile (but not run) a program from a file:

rustc foo.rs

Read the tutorial to get started:

http://static.rust-lang.org/doc/master/tutorial.html

Then join the IRC channel to ask questions:

http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust

And once you're ready to start working on the compiler itself, here's how
you can compile it from the source code:

git clone https://github.com/mozilla/rust.git && cd rust && ./configure
&& make install

Good luck! :)


On Fri, May 16, 2014 at 7:57 PM, Ricardo Brandão wrote:

> Hi ALL,
>
> I'd like to introduce my self. I'm a Computer Engineer and I've worked
> with Embedded Computer for 12 years before work with IT Management for 10
> years.
>
> Now I became a Mozillian, studying Firefox OS, Gonk and Gecko and very
> excited to come back to technical "world".
>
> Last week I attended a lecture on FISL (a Free Software Forum) in Brazil
> about Rust and Servo. From Bruno Abinader
>
> I'm very interested on these project and I'd like to join it.
>
> I have a good experience with C and Assembly, but not exactly with
> Unix-like platform. I was used to program directly to the board. I've used
> ZWorld Boards (nowadays ZWorld became Digi).
>
> But I tried to see some "Easy" bugs (on rust and servo repos) to at least
> understand, but I'm confused.
>
> Could you give me some step-by-step, how begin the study of project, which
> documents to read, etc? Remember I'm not an expert on Makefile and C for
> Unix-like platforms. Well, I already worked with but in small projects.
>
> Thanks in advance!
>
> --
> Ricardo Brandão
> http://www.programonauta.com.br
>
> __@
> ._  \ >_
> (_) /  (_)
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] rust block comments

[Benjamin Striegel]

Originally, ancient versions of Rust allowed you to nest block comments.
Then we decided this was too surprising and too hard to parse, so we took
it out. Then we decided that this was too useful to exclude so we added it
back in, but apparently this time we forgot to update the manual. Just
another day in the life of Rust! :)


On Wed, Apr 30, 2014 at 3:00 AM, Phil Dawes  wrote:

> Hello!
>
> Could somebody clarify the block comments structure in rust please? The
> manual says 'Comments in Rust code follow the general C++ style of line and
> block-comment forms, with no nesting of block-comment delimiters.'
> http://static.rust-lang.org/doc/master/rust.html#comments
>
> However the grammar looks like it parses nesting of block comment
> delimiters, and e.g. the following compiles:
>
> fn main() {
> /* /* */ */ println!("YEAH!");
> }
>
> Is the manual wrong or have I mis-understood it? (racer performs comment
> cleaning which is why I'm interested)
>
> Thanks,
>
> Phil
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Optimizing pattern bindings to not copy anything at runtime

[Benjamin Striegel]

 > We're just being overly restrictive for legacy reasons.

This same sentiment appears in https://github.com/rust-lang/rfcs/pull/48 .
How many more rules are we imposing that exist only for "legacy reasons"?
Is addressing them all a priority for 1.0?


On Wed, Apr 23, 2014 at 10:09 PM, Niko Matsakis  wrote:

> Ah, neat. I have been wanting to do this optimization for function
> parameters for a long time, but I hadn't thought about it for other
> kinds of bindings. Better yet, I think by-copy vs by-move is a red
> herring. The optimization applies equally well in both scenarios.
>
> That said, we do have to be a bit careful about mutability. Even just
> considering by-move locals, for example, it is possible to have code
> like the following:
>
> let mut x = something();
> let y = x;
> x = something_else();
>
> If we just made y a pointer to x, we'd be in trouble.
>
> Also, this statement isn't quite right:
>
> > 2. The only things that can be moved out of in Rust are locals and
> rvalues.
>
> You could e.g. move out of x.y.z. Moreover, I think we can support a
> lot more. As part of #5016 I plan to allow you to continue the parts
> of a struct that have not been moved out of. Better yet, if you
> replace the moved out fields, you can go back to using the struct
> again:
>
> let foo = ...;
> let a = foo.a; // moves out of foo.a
> let b = foo.b; // moves out of foo.b
> foo.a = ...;
> foo.b = ...;
> use(foo);
>
> This all basically falls out of the analysis we're currently doing,
> which tracks the precise deinitialized paths (e.g., foo.a, foo.b,
> etc). We're just being overly restrictive for legacy reasons. I'm
> working on a patch right now that should make it easy to change that.
>
> At some point, I think we could even enable moves out of &mut, as long
> as you replace the value before failure could occur. This would allow
> tree-maps and the like to do rotations just as you do in C. But I
> haven't tried to write formal rules for this yet.
>
>
> Niko
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Announcing the newest member of Mozilla's Rust team, Aaron Turon

[Benjamin Striegel]

Welcome Aaron! And "LVars" sounds familiar... was that something that
Lindsey Kuper was working on?


On Mon, Apr 21, 2014 at 5:18 PM, Alex Crichton  wrote:

> Welcome Aaron! I'm so excited to have you with us!
>
> On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson 
> wrote:
> > Hey there, Rusticators,
> >
> > Grand news! Starting today Aaron Turon is joining the Rust team. Aaron
> did
> > his PhD thesis on concurrency at Northeastern University, where he
> published
> > widely-noted papers on 'reagents' and 'LVars'. He will be focusing on
> making
> > Rust's standard libraries the best they can be. He's aturon on IRC; say
> 'hi'
> > when you see him.
> >
> > Welcome aboard, Aaron.
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] 0.10 prerelease testing

[Benjamin Striegel]

In terms of making hello world nice in 0.10, I prefer to simply put
something else in the format string in order to clarify what the first
argument is there for:

fn main() {
let x = "world";
println!("Hello, {:s}!", x);
}

Also remember that saying `println!("Hello, world!");` by itself still
works.


On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik wrote:

> I compiled from source just yesterday, but everything's been going
> swimmingly!
>
> I just have one comment on 0.10: It seems like println was removed
> from the prelude. While I can totally appreciate that most people will
> use println!, which is automatically use-able, it _is_ making my
> 'hello world' examples significantly more complex, since basically
> every one of them needs to either import println or use println!("{}",
> foo);
>
> I'm not sure if this is a good or bad thing, just wanted to raise that
> as a possible issue.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Anyone in DC or Pittsburgh? (was: Anyone in NYC?)

[Benjamin Striegel]

My schedule is pretty tight, but I'll be in the DC area through next
Tuesday if anyone would like to hang out or get a drink sometime! And I'll
be in Pittsburgh all through April, and I'm pretty sure there's at least a
few Pittsburgh-based contributors who are long overdue for a meetup. :)

On Fri, Mar 14, 2014 at 8:16 PM, Davis Silverman wrote:

> I was just about to send an email regarding a DC Rust meetup group!
>
> I thought about setting up a Rust meetup.com account, but I dont have the
> funds to waste, but can we gague interest perhaps? I would love to gather
> sometime soon and talk about Rust!
>
> Sincerely,
> ~~Davis Silverman
> ~Sinistersnare
>
>
>
> On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel  > wrote:
>
>> Not NYC, but I'm in the DC area until next week if anyone wants to hang
>> out. :)
>>
>> Maybe we need some kind of general geographic Rust meet-up service...
>>
>>
>> On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager  wrote:
>>
>>>  I'd be in.
>>>
>>>
>>> On Thursday, March 13, 2014, Clark Gaebel  wrote:
>>>
>>>> Hey I'm in NYC and think some sort of rust meet-up would be neat.
>>>> Anyone out there?
>>>>
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] to ! or not to !

[Benjamin Striegel]

> macros are needed for most uses of print functions
since you generally want variable number of arguments

In addition to that a plain function wouldn't be able to verify a format
string at compile-time.


On Fri, Mar 14, 2014 at 5:55 PM, Jack Moffitt  wrote:

> A suffix ! means that you are using a macro. In this case there is no
> difference, but macros are needed for most uses of print functions
> since you generally want variable number of arguments, which can only
> be done with macros in rust.
>
> jack.
>
> On Fri, Mar 14, 2014 at 3:52 PM, Renato Lenzi  wrote:
> > Simple question:
> >
> > println("hello");
> >
> > or
> >
> > println!("hello!");
> >
> > Why (or when) should we use one or the other form?? Differences?
> >
> > Regards.
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Anyone in NYC?

[Benjamin Striegel]

Not NYC, but I'm in the DC area until next week if anyone wants to hang
out. :)

Maybe we need some kind of general geographic Rust meet-up service...


On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager  wrote:

> I'd be in.
>
>
> On Thursday, March 13, 2014, Clark Gaebel  wrote:
>
>> Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone
>> out there?
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "Virtual fn" is a bad idea

[Benjamin Striegel]

Is it correct for me to assume that, even if accepted, virtual things will
be behind a feature flag for 1.0? If so, then I think that will be enough
friction to cause library authors to favor traits instead, especially if
users of virtual-using-libraries would have to turn on the feature flag as
well.


On Thu, Mar 13, 2014 at 12:34 AM, comex  wrote:

> Small comments:
>
> - C++ RTTI is known for being slow, because dynamic_cast has to
> traverse the inheritance tree to decide whether the requested type is
> in there.  LLVM and I think something else I've seen (V8?) improve on
> it by having a master enum of class IDs and then just testing whether
> the object's class ID is between the beginning and end of the list of
> subclasses of the requested one.  As long as this is about
> performance, I think it would be nice to do that instead of using an
> implementation people are going to be motivated to replace with custom
> code anyway.  It would require some kind of enum-based syntax to be
> able to enumerate all the subclasses in one compilation unit, but in
> my opinion that would be an improvement in some ways.  For instance,
> it would be more sane to implement pattern matching for - maybe not
> very important for DOM nodes, but perhaps other things.
>
> (While not as commonly faulted, virtual methods themselves are also
> something of a worst case compared to situations where the compiler
> might know in superclass X - either because the code was written using
> pattern matching or because of some slightly fancy magic - that the
> class is either a Y or a Z, the only two subclasses, and use regular
> branches with inlining, instead of having to go with a full-blown
> indirect jump for everything that differs between subclasses.)
>
> - Alternately, if a C++-like interface is really the right answer...
> for the reasons mentioned elsewhere in the thread (orthogonality/more
> than one way to do it, bad interfaces, and all that), it should still
> be heavily discouraged.  That is, only a small number of projects with
> pressing performance needs similar to this particular object tree
> scenario ought to be using it.  But in that case, I don't think it's
> necessary to make it "nice".  In fact, I think it should be nasty: if
> people think like me (...but I don't design serious libraries...),
> then feature gates requiring one line of code to get past are not
> going to convince them to rethink their design; they will just
> bludgeon through them in order to write Java code in Rust.  Servo can
> live with one part of it using nasty macros instead of nice language
> features.
>
> And in C, in my opinion, it's not even particularly nasty even without
> macros.  I appreciate that Rust would need macros to ensure
> compile-time safety, but it can't be that bad...
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Benjamin Striegel]

> Should the mailing list be involved in this process, as a way to get more
people discussing RFCs?

I'm using Github's "watch" feature on the RFC repo so that I am
automatically emailed whenever a new PR pops up or a discussion occurs.
These emails then get filtered to a "Rust RFCs" folder for easier review.
Perhaps this approach could work for others as well.


On Wed, Mar 12, 2014 at 6:42 AM, Simon Sapin  wrote:

> On 12/03/2014 01:11, Brian Anderson wrote:
>
>> * Fork the RFC repohttp://github.com/rust-lang/rfcs
>>
>> * Copy `-template.md` to `active/-my-feature.md` (where
>> 'my-feature' is descriptive. don't assign an RFC number yet).
>> * Fill in the RFC
>> * Submit a pull request. The pull request is the time to get review of
>> the design from the larger community.
>> * Build consensus and integrate feedback. RFCs that have broad support
>> are much more likely to make progress than those that don't receive any
>> comments.
>> * Eventually, somebody on the [core team] will either accept the RFC by
>> merging the pull request and assigning the RFC a number, at which point
>> the RFC is 'active', or reject it by closing the pull request.
>>
>
> Should the mailing list be involved in this process, as a way to get more
> people discussing RFCs? (Maybe automatically with a bot sending email for
> every PR in the RFC repo.)
>
> On the other hand, we probably don't want to fragment the discussion
> between GitHub issues and email.
>
> --
> Simon Sapin
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Benjamin Striegel]

Rather than discuss this here, let's start dogfooding:

https://github.com/rust-lang/rfcs/pull/2


On Wed, Mar 12, 2014 at 3:54 AM, Flaper87  wrote:

>
>
>
> 2014-03-12 2:11 GMT+01:00 Brian Anderson :
>
> [snip]
>
>
>> -
>>
>> Many changes, including bug fixes and documentation improvements can be
>> implemented and reviewed via the normal GitHub pull request workflow.
>>
>> Some changes though are "substantial", and we ask that these be put
>> through a bit of a design process and produce a consensus among the Rust
>> community and the [core team].
>>
>> The "RFC" (request for comments process) is intended to provide a
>> consistent and controlled path for new features to enter the language and
>> standard libraries, so that all stakeholders can be confident about the
>> direction the language is evolving in.
>>
>> ## When you need to follow this process
>>
>> You need to follow this process if you intend to make "substantial"
>> changes to the Rust distribution. What constitutes a "substantial" change
>> is evolving based on community norms, but may include the following.
>>
>>   - Any semantic or syntactic change to the language that is not a bugfix.
>>   - Changes to the interface between the compiler and libraries,
>> including lang items and intrinsics.
>>   - Additions to `std`
>>
>> Some changes do not require an RFC:
>>
>>   - Rephrasing, reorganizing, refactoring, or otherwise "changing shape
>> does not change meaning".
>>   - Additions that strictly improve objective, numerical quality criteria
>> (warning removal, speedup, better platform coverage, more parallelism, trap
>> more errors, etc.)
>>   - Additions only likely to be _noticed by_ other developers-of-rust,
>> invisible to users-of-rust.
>>
>> If you submit a pull request to implement a new feature without going
>> through the RFC process, it may be closed with a polite request to submit
>> an RFC first.
>>
>> ## What the process is
>>
>> In short, to get a major feature added to Rust, one must first get the
>> RFC merged into the RFC repo as a markdown file. At that point the RFC is
>> 'active' and may be implemented with the goal of eventual inclusion into
>> Rust.
>>
>> * Fork the RFC repo http://github.com/rust-lang/rfcs
>> * Copy `-template.md` to `active/-my-feature.md` (where
>> 'my-feature' is descriptive. don't assign an RFC number yet).
>>
>
> What about using the PR's number? That means we'll end up with some gaps
> between accepted RFCs but... just thinking aloud.
>
>
>
>> * Fill in the RFC
>> * Submit a pull request. The pull request is the time to get review of
>> the design from the larger community.
>> * Build consensus and integrate feedback. RFCs that have broad support
>> are much more likely to make progress than those that don't receive any
>> comments.
>> * Eventually, somebody on the [core team] will either accept the RFC by
>> merging the pull request and assigning the RFC a number, at which point the
>> RFC is 'active', or reject it by closing the pull request.
>>
>
> We should also use tags: `Rejected` / `Approved`
>
> I'm wondering if we should keep rejected RFCs too and not just as closed
> PRs. If for some reason, this repo is moved out of GH in the future, we'd
> loose a bunch of RFC history. We could keep the first rejected RFC for a
> type of change and reject future duplicated RFCs by linking them to that
> RFC. Not sure about this, though.
>
>
> Once an RFC becomes active then authors may implement it and submit the
>> feature as a pull request to the Rust repo. An 'active' is not a rubber
>> stamp, and in particular still does not mean the feature will ultimately be
>> merged; it does mean that in principle all the major stakeholders have
>> agreed to the feature and are amenable to merging it.
>>
>> Modifications to active RFC's can be done in followup PR's. An RFC that
>> makes it through the entire process to implementation is considered
>> 'complete' and is moved to the 'complete' folder; an RFC that fails after
>> becoming active is 'inactive' and moves to the 'inactive' folder.
>>
>
> We also need a way to track who's working on that RFC. Should an RFC bug
> be created in Rust's repo and be linked to the real RFC ? This way folks
> can raise their hands and work on the RFC, it's also a good place for
> follow-up discussions on the work happening for that RFC, etc. The person
> proposing the RFC is not necessarily the one that will work on it.
>
> I was going to suggest having a way to automatically close and move the
> active RFC under the complete folder but I think this process requires some
> double checking from the [core team] so I'd prefer keeping it that way.
>
>
>
>> ### Help this is all too informal!
>>
>> The process is intended to be as lightweight as reasonable for the
>> present circumstances. As usual, we are trying to let the process be driven
>> by consensus and community norms, not impose more structure than necessary.
>>
>
> FWIW, I've seen a similar process being i

Re: [rust-dev] Language to replace C

[Benjamin Striegel]

I'm seeing unnecessarily hostile and dismissive comments from several
participants here. If you can't be civil, then ignore the thread and move
on.


On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang  wrote:

> If I select Rust as my main language, I don't think I have any reason to
> write new code in Go. Go away!
> 2014年3月5日 上午3:44于 "John Mija" 写道：
>
> Every time there is a new language, developers have to start to developing
>> from scratch the same algorithms.
>> The alternative has been to use C libraries already built since is much
>> easier to interface with other languages and a lot of languages will let
>> you call C functions directly.
>>
>> But C language is unsafe and there is a penalty performance at binding.
>> Besides, it is harder to debug incorrect C code.
>>
>> So, why don't use a simple language but safe like Go?
>> The Go compilers create a single intermediate file representing the
>> "binary assembly" of the compiled package, ready as input for the linker:
>> http://golang.org/cmd/gc/
>>
>> I'm supposed that a linker could be built to link that intermediate file
>> together to a Rust program.
>>
>> The main advantage is that you would use a simpler language to build
>> algorithms and code of lower level (asm), wich could be linked from other
>> languages.
>> Rust is a language more complex to replace to C like "universal language".
>>
>> Note: I love both languages; Go for web apps and Rust for everything else
>> (mobile and desktop apps, and servers).
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] issue numbers in commit messages

[Benjamin Striegel]

Having read this week's meeting notes on this topic:

> we'll get bors to warn people about not putting the issue number in
commit messages

Can anyone elaborate on what this will entail? By "commit message" do you
mean the honest-to-god git commit message, or the Github PR message, or
both? What form will the warning take, and how easy will it be to ignore it
in order to accomodate one-off contributors submitting typo fixes?


On Tue, Feb 18, 2014 at 8:06 AM, Huon Wilson  wrote:

>  I wrote a quick & crappy script that automates going from commit -> PR:
>
> #!/bin/sh
>
> if [ $# -eq 0 ]; then
> echo 'Usage: which-pr COMMIT'
> exit 0
> fi
>
> git log master ^$1 --ancestry-path --oneline --merges | \
> tail -1 | \
> sed 's@.*#\([0-9]*\) : .*@http://github.com/mozilla/rust/pull/\1@'
>
> Putting this in your path gives:
>
> $ which-pr 6555b04
> http://github.com/mozilla/rust/pull/12345
>
> $ which-pr a02b10a0621adfe36eb3cc2e46f45fc7ccdb7ea2
> http://github.com/mozilla/rust/pull/12162
>
> Of course, I'm sure there are corner cases that don't work, and it's
> definitely not as usable as something directly encoded in the commit.
>
>
> Huon
>
>
>
> On 18/02/14 13:17, Nick Cameron wrote:
>
>  Right, that is exactly what I want to see, just on every commit. For
> example,
> https://github.com/mozilla/rust/commit/a02b10a0621adfe36eb3cc2e46f45fc7ccdb7ea2.
> has none of that info and I can't see any way to get it (without the kind
> of Git-fu suggested earlier). (Well, I can actually see that r=nikomatsakis
> from the comments at the bottom, but I can't see how that r+ came about,
> whether there was any discussion, whether there was an issue where this was
> discussed or not, etc.).
>
>
> On Tue, Feb 18, 2014 at 3:02 PM, Corey Richardson wrote:
>
>>
>> https://github.com/mozilla/rust/commit/25147b2644ed569f16f22dc02d10a0a9b7b97c7e
>> seems to provide all of the information you are asking for? It
>> includes the text of the PR description, the PR number, the name of
>> the branch, and who reviewed it. I agree with your premise but I'm not
>> sure I agree that the current situation isn't adequate. But I wouldn't
>> be opposed to such a change.
>>
>> On Mon, Feb 17, 2014 at 8:54 PM, Nick Cameron  wrote:
>> > Whether we need issues for PRs is a separate discussion. There has to be
>> > _something_ for every commit - either a PR or an issue, at the least
>> there
>> > needs to be an r+ somewhere. I would like to see who reviewed something
>> so I
>> > can ping someone with questions other than the author (if they are
>> offline).
>> > Any discussion is likely to be useful.
>> >
>> > So the question is how to find that, when necessary. GitHub sometimes
>> fails
>> > to point to the info. And when it does, you do not know if you are
>> missing
>> > more info. For the price of 6 characters in the commit message (or "no
>> > issue"), we know with certainty where to find that info and that we are
>> not
>> > missing other potentially useful info. This would not slow down
>> development
>> > in any way.
>> >
>> > Note that this is orthogonal to use of version control - you still need
>> to
>> > know Git in order to get the commit message - it is about how one can go
>> > easily from a commit message to meta-data about a commit.
>> >
>> >
>> > On Tue, Feb 18, 2014 at 12:53 PM, Kevin Ballard  wrote:
>> >>
>> >> This is not going to work in the slightest.
>> >>
>> >> Most PRs don't have an associated issue. The pull request is the issue.
>> >> And that's perfectly fine. There's no need to file an issue separate
>> from
>> >> the PR itself. Requiring a referenced issue for every single commit
>> would be
>> >> extremely cumbersome, serve no real purpose aside from aiding an
>> >> unwillingness to learn how source control works, and would probably
>> slow
>> >> down the rate of development of Rust.
>> >>
>> >> -Kevin
>> >>
>> >> On Feb 17, 2014, at 3:50 PM, Nick Cameron  wrote:
>> >>
>> >> At worst you could just use the issue number for the PR. But I think
>> all
>> >> non-trivial commits _should_ have an issue associated. For really tiny
>> >> commits we could allow "no issue" or '#0' in the message. Just so long
>> as
>> >> the author is being explicit, I think that is OK.
>> >>
>> >>
>> >> On Tue, Feb 18, 2014 at 12:16 PM, Scott Lawrence 
>> wrote:
>> >>>
>> >>> Maybe I'm misunderstanding? This would require that all commits be
>> >>> specifically associated with an issue. I don't have actual stats, but
>> >>> briefly skimming recent commits and looking at the issue tracker, a
>> lot of
>> >>> commits can't be reasonably associated with an issue. This
>> requirement would
>> >>> either force people to create fake issues for each commit, or to
>> reference
>> >>> tangentially-related or overly-broad issues in commit messages,
>> neither of
>> >>> which is very useful.
>> >>>
>> >>> Referencing any conversation that leads to or influences a commit is a
>> >>> good ide

Re: [rust-dev] [Boston] Rust talk on Monday

[Benjamin Striegel]

Though if you don't record it, you can offer to give the presentation
remotely at the monthly Bay Area Rust Meetup. :)


On Fri, Feb 14, 2014 at 12:18 PM, Ian Daniher wrote:

> I can make sure it's recorded & put on youtube.
>
>
> On Fri, Feb 14, 2014 at 12:01 PM, Jack Moffitt  wrote:
>
>> This sounds pretty interesting. Will it be recorded at all?
>>
>> jack.
>>
>> On Fri, Feb 14, 2014 at 9:29 AM, Ian Daniher 
>> wrote:
>> > Hello fellow Rustafarians!
>> >
>> > Monday the 17th, at 6pm, at 1000 Olin Way, Needham, MA, there will be
>> free
>> > pizza for anyone who shows up.
>> >
>> > I'll be giving a ~30m talk on my work using Rust for software radio
>> > demodulation, decoding, and parsing, focusing on some neat
>> datastructure and
>> > architectural decisions I've made.
>> >
>> > The focus of the talk will be on https://github.com/ade-ma/LibRedio, my
>> > preliminary work on a sort of "gnuradio-lite" my capstone team is using
>> for
>> > making low-cost automation tools.
>> >
>> > Contact me with questions, comments, and RSVPs!
>> >
>> > Best,
>> > --
>> > Ian Daniher
>> >
>> > ___
>> > Rust-dev mailing list
>> > Rust-dev@mozilla.org
>> > https://mail.mozilla.org/listinfo/rust-dev
>> >
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] What form should the official Rust binary installers for Unixes take?

[Benjamin Striegel]

> there is a plan for llvm before 1.0.

What does this refer to? Last I checked we were certain to still be using a
custom LLVM as of 1.0.


On Tue, Feb 11, 2014 at 1:18 PM, Luca BRUNO  wrote:

> Tom Lee  wrote:
>
> > I've cced Luca Bruno in since I think he's been keeping a closer eye
> > on the details.
>
> Thanks for copying, I was already lurking the thread. For the sake of
> completeness, I've been in talk with several Mozillers and Debian guys
> in the last few days to try to sort out all the details, hopefully in
> time for 0.10. I'm currently waiting for some final quotable feedback,
> I'll try to post all the details after that.
>
> > Relevant link on the wiki:
> > https://github.com/mozilla/rust/wiki/Note-packaging
> >
> > At a glance, most of those tickets still seem to be open.
> > Helping us work through some of the thornier issues would be a huge
> > help.
>
> In fact, rust devs have been very collaborative and most of the issues
> are mostly fixed or being addressed. rpath should be ok, libuv has been
> upstreamed and there is a plan for llvm before 1.0.
> Bootstrapping will stay as is and hopefully be accepted (with some
> workaround processes) also in Debian.
>
> I can't speak for Fedora/RH, but looks like things are consistently
> improving on this front. And many third-party repositories already
> exists for those who prefer the bleeding-edge :)
>
> Cheers, Luca
>
> --
>   .''`.  |   ~<[ Luca BRUNO ~ (kaeso) ]>~
>  : :'  : | Email: lucab (AT) debian.org ~ Debian Developer
>  `. `'`  | GPG Key ID: 0x3BFB9FB3   ~ Free Software supporter
>`-| HAM-radio callsign: IZ1WGT   ~ Networking sorcerer
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] What form should the official Rust binary installers for Unixes take?

[Benjamin Striegel]

> We can also attempt to package Rust with various of the most common
package managers: homebrew, macports, dpkg, rpm.

It would be great to have these for the point releases, but do all of these
allow for nightly builds?


On Thu, Feb 6, 2014 at 7:35 PM, Brian Anderson wrote:

> Hey.
>
> One of my goals for 0.10 is to make the Rust installation and upgrade
> experience better. My personal ambitions are to make Rust installable with
> a single shell command, distribute binaries, not source, and to have both
> nightlies and point releases.
>
> Since we're already able to create highly-compatible snapshot compilers,
> it should be relatively easy to extend our snapshot procedure to produce
> complete binaries, installable via a cross-platform shell script. This
> would require the least amount of effort and maintenance because we don't
> need to use any specific package managers or add new bots, and a single
> installer can work on all Linuxes.
>
> We can also attempt to package Rust with various of the most common
> package managers: homebrew, macports, dpkg, rpm. There community-maintained
> packages for some of these already, so we don't necessarily need to
> redevelop from scratch if we just want to adopt one or all of them as
> official packages. We could also create a GUI installer for OS X, but I'm
> not sure how important that is.
>
> What shall we do?
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust's 2013 issue churn

[Benjamin Striegel]

Awesome! What a cool find. As well, this lends credence to my previously
unfounded suspicion that we were one of the most prolific users of Github's
issue tracking system. This should give us some leverage the next time that
we feel the need to complain about the UI. :P


On Wed, Feb 5, 2014 at 7:20 PM, Alex Crichton  wrote:

> Some of you may have already seen GitHub's new State of the Octoverse
> 2013 at http://octoverse.github.com/
>
> I'd just like to point out that the rust repository closed the second
> most number of issues (6408) on all of GitHub. Just to reiterate, out
> of the millions of repositories on GitHub, we closed the *second
> highest* number of issues!
>
> Congratulations to everyone, this was truly a community effort. I look
> forward to closing even more issues this year!
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla

[Benjamin Striegel]

Congratulations!


On Mon, Feb 3, 2014 at 10:11 PM, Tim Kuehn  wrote:

> Fantastic! Good luck, Nick!
>
>
> On Mon, Feb 3, 2014 at 6:51 PM, Alex Crichton  wrote:
>
>> Welcome Nick!
>>
>> I can't wait to see that 1.0 issue count go down!
>>
>> On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson 
>> wrote:
>> > Hi Rusties,
>> >
>> > I'm just thrilled to announce today that Nick Cameron (nrc) has joined
>> > Mozilla's Rust team full-time. Nick has a PhD in programming language
>> theory
>> > from Imperial College London and has been hacking on Gecko's graphics
>> and
>> > layout for two years, but now that he's all ours you'll be seeing him
>> > eradicate critical Rust bugs by the dozens. Good luck, Nick, and
>> welcome to
>> > the party.
>> >
>> > Regards,
>> > Brian
>> > ___
>> > Rust-dev mailing list
>> > Rust-dev@mozilla.org
>> > https://mail.mozilla.org/listinfo/rust-dev
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Unify closure and proc declaration syntax?

[Benjamin Striegel]

It might be good to revisit proc syntax, but I don't think that it's yet
time for that. There's a nebulous plan in the works involving
reimplementing closures as traits (or... something?) and how that shakes
out would likely impact the syntax that we want to provide.


On Mon, Feb 3, 2014 at 11:26 AM, Jake Kerr  wrote:

> Hello rust-dev,
>
> I imagine there are reasons I've not considered for why proc
> declaration syntax is the way it is, but I couldn't find any
> discussion on this list or in the issues so thought I'd make a
> proposal.
>
> I think it would be nice if procs and closures had a more similar syntax.
> Specifically I'd like to see proc loose it's function like ()
> parameter list and gain the block like || params list as closures
> have.
>
> So rather than the current:
> spawn(proc(x,y) { /* Do some work. */  });
>
> We would write:
> spawn(proc |x,y| { /* Do some work. */  });
>
> A minor change, for sure, but I find the later easier to visually
> parse and recognize as a closure. With the current syntax I find that
> for a split second it looks to me like a function call to some
> function "proc" with a block after it.
> I thought for a moment that maybe proc was a function with a
> final hidden block argument and that this was a magic syntactic sugar
> for giving this "proc" function a block (kind of like the old do
> syntax) but then I read the parser and learned that proc is in fact part
> of the syntax.
>
> There are probably some caveats that I haven't considered since I'm not
> 100% familiar with all of the closure types. If there is a glaring
> reason why this is a bad idea please do tell; else let's discuss.
>
> Thanks for reading!
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Benjamin Striegel]

After sleeping on it I'm not convinced that this would be a net improvement
over our current situation. With a few caveats I'm really rather happy with
the syntax as it is.


On Sun, Feb 2, 2014 at 8:55 AM, Jason Fager  wrote:

> I'm not a huge fan of this proposal.  It makes declarations longer, and it
> removes the visual consistency of Foo everywhere, which I think
> introduces its own pedagogical issue.
>
> The recent addition of default type parameters, though, makes me think
> there's a reasonable change that increases consistency and shortens
> declarations in a few common cases.
>
> From what I understand, the reason we can't just have
>
> impl Trait for Foo
>
> is because it's ambiguous whether T and U are intended to be concrete or
> generic type names; i.e.,
>
> impl Trait for Foo
>
> tells the compiler that we expect U to be a concrete type name.
>
> Our new default type parameter declarations look like:
>
> struct Foo
>
> So what if to actually make generic types concrete, we always used the '='?
>
> struct Foo
> impl Trait for Foo
>
> This saves a character over 'impl Trait for Foo', solves
> the greppability problem, and makes intuitive sense given how defaults are
> declared.
>
> It also has a nice parallel with how ':' is used - ':' adds restrictions,
> '=' fully locks in place.  So what is today something like
>
> impl Trait for Foo
>
> would become
>
> impl Trait for Foo
>
> The rule would be that the first use of a type variable T would introduce
> its bounds, so for instance:
>
> impl Trait for Foo
>
> would be fine, and
>
> impl Trait for Foo
>
> would be an error.
>
> More nice fallout:
>
> struct Foo
> impl Foo {
> fn one(a: A) -> B
> fn two(a: A) -> B
> fn three(a: A) -> B
> }
>
> means that if I ever want to go back and change the name of Bar, I only
> have to do it in one place, or if Bar is actually some complicated type, I
> only had to write it once, like a little local typedef.
>
> I'm sure this has some glaring obvious flaw I'm not thinking of.  It would
> be nice to have less syntax for these declarations, but honestly I'm ok
> with how it is now.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 1, 2014 at 5:39 PM, Corey Richardson  wrote:
>
>> Hey all,
>>
>> bjz and I have worked out a nice proposal[0] for a slight syntax
>> change, reproduced here. It is a breaking change to the syntax, but it
>> is one that I think brings many benefits.
>>
>> Summary
>> ===
>>
>> Change the following syntax:
>>
>> ```
>> struct Foo { ... }
>> impl Trait for Foo { ... }
>> fn foo(...) { ... }
>> ```
>>
>> to:
>>
>> ```
>> forall struct Foo { ... }
>> forall impl Trait for Foo { ... }
>> forall fn foo(...) { ... }
>> ```
>>
>> The Problem
>> ===
>>
>> The immediate, and most pragmatic, problem is that in today's Rust one
>> cannot
>> easily search for implementations of a trait. Why? `grep 'impl Clone'` is
>> itself not sufficient, since many types have parametric polymorphism. Now
>> I
>> need to come up with some sort of regex that can handle this. An easy
>> first-attempt is `grep 'impl(<.*?>)? Clone'` but that is quite
>> inconvenient to
>> type and remember. (Here I ignore the issue of tooling, as I do not find
>> the
>> argument of "But a tool can do it!" valid in language design.)
>>
>> A deeper, more pedagogical problem, is the mismatch between how `struct
>> Foo<...> { ... }` is read and how it is actually treated. The
>> straightforward,
>> left-to-right reading says "There is a struct Foo which, given the types
>> ...
>> has the members ...". This might lead one to believe that `Foo` is a
>> single
>> type, but it is not. `Foo` (that is, type `Foo` instantiated with
>> type
>> `int`) is not the same type as `Foo` (that is, type `Foo`
>> instantiated
>> with type `uint`). Of course, with a small amount of experience or a very
>> simple explanation, that becomes obvious.
>>
>> Something less obvious is the treatment of functions. What does `fn
>> foo<...>(...) { ... }` say? "There is a function foo which, given types
>> ...
>> and arguments ..., does the following computation: ..." is not very
>> adequate.
>> It leads one to believe there is a *single* function `foo`, whereas there
>> is
>> actually a single `foo` for every substitution of type parameters! This
>> also
>> holds for implementations (both of traits and of inherent methods).
>>
>> Another minor problem is that nicely formatting long lists of type
>> parameters
>> or type parameters with many bounds is difficult.
>>
>> Proposed Solution
>> =
>>
>> Introduce a new keyword, `forall`. This choice of keyword reads very well
>> and
>> will not conflict with any identifiers in code which follows the [style
>> guide](https://github.com/mozilla/rust/wiki/Note-style-guide).
>>
>> Change the following declarations from
>>
>> ```
>> struct Foo { ... }
>> impl Trait for Foo { ... }
>> fn foo(...) { ... }
>> ```
>>
>> to:
>>
>> ```
>> forall struct Foo { ... }
>> forall impl Trait for Foo { ... }
>

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Benjamin Striegel]

> How about supporting type aliases as Scala does?

In theory I think that should be achievable today, using trait inheritance:

trait MyT : Clone, Eq {}

...at least, I *think* we allow multiple trait inheritance. Not sure what
the syntax is!


On Sat, Feb 1, 2014 at 6:12 PM, Vladimir Lushnikov <
vladi...@slate-project.org> wrote:

> Placing type bounds before the name of the thing you are trying to declare
> feels unnatural to me. And the generic block is far too much boilerplate!
>
> How about supporting type aliases as Scala does? So you write:
>
>   type MyT = Clone + Eq
>   fn foo(t: T, u: U) -> ...
>
> and the 'type' is just an alias for any type that has Clone + Eq?
>
> Obviously the above only solves repeating yourself for complex type
> constraints.
>
> Also, reusing 'for' would be confusing as well, because you expect a loop
> there, not a generic type bound. How about 'any':
>
> any  fn foo (t: T, u: U) -> ...
>
> ?
>
>
> On Sat, Feb 1, 2014 at 11:06 PM, Benjamin Striegel  > wrote:
>
>> Another point in favor of this plan is that it would eliminate the need
>> to put type parameters directly after the `impl`, which to be honest *is*
>> pretty weird and inconsistent with the rest of the language. But I'm still
>> not sure how I feel about the look of it:
>>
>> for  fn foo(t: T, u: U) -> (T, U) {
>>
>> If you choose *not* to wrap after the type parameters there, you're
>> really obscuring what the heck you're trying to declare.
>>
>> Heck, maybe what we're really asking for is for the ability to have
>> "generic blocks" within which type parameters can be declared once:
>>
>> for  {
>> fn foo(t: T, u: U) -> (T, U) {
>>
>> ...but that's even *more* boilerplate!
>>
>>
>>
>>
>> On Sat, Feb 1, 2014 at 5:59 PM, Benjamin Striegel > > wrote:
>>
>>> > Yes, and I don't have a solution for that.
>>>
>>> Well, it's not like we don't already stumble here a bit, what with
>>> requiring ::<> instead of just <>. Not sure how much other people value the
>>> consistency here.
>>>
>>>
>>> On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson wrote:
>>>
>>>> On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
>>>>  wrote:
>>>> > First of all, why a new keyword? Reusing `for` here would be totally
>>>> > unambiguous. :P And also save us from creating the precedent of
>>>> multi-word
>>>> > keywords.
>>>> >
>>>>
>>>> I'd be equally happy with for instead of forall.
>>>>
>>>> > Secondly, currently Rust has a philosophy of use-follows-declaration
>>>> (i.e.
>>>> > the syntax for using something mirrors the syntax for declaring it).
>>>> This
>>>> > would eliminate that.
>>>> >
>>>>
>>>> Yes, and I don't have a solution for that.
>>>>
>>>
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Benjamin Striegel]

Another point in favor of this plan is that it would eliminate the need to
put type parameters directly after the `impl`, which to be honest *is*
pretty weird and inconsistent with the rest of the language. But I'm still
not sure how I feel about the look of it:

for  fn foo(t: T, u: U) -> (T, U) {

If you choose *not* to wrap after the type parameters there, you're really
obscuring what the heck you're trying to declare.

Heck, maybe what we're really asking for is for the ability to have
"generic blocks" within which type parameters can be declared once:

for  {
fn foo(t: T, u: U) -> (T, U) {

...but that's even *more* boilerplate!




On Sat, Feb 1, 2014 at 5:59 PM, Benjamin Striegel wrote:

> > Yes, and I don't have a solution for that.
>
> Well, it's not like we don't already stumble here a bit, what with
> requiring ::<> instead of just <>. Not sure how much other people value the
> consistency here.
>
>
> On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson  wrote:
>
>> On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
>>  wrote:
>> > First of all, why a new keyword? Reusing `for` here would be totally
>> > unambiguous. :P And also save us from creating the precedent of
>> multi-word
>> > keywords.
>> >
>>
>> I'd be equally happy with for instead of forall.
>>
>> > Secondly, currently Rust has a philosophy of use-follows-declaration
>> (i.e.
>> > the syntax for using something mirrors the syntax for declaring it).
>> This
>> > would eliminate that.
>> >
>>
>> Yes, and I don't have a solution for that.
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Benjamin Striegel]

> Yes, and I don't have a solution for that.

Well, it's not like we don't already stumble here a bit, what with
requiring ::<> instead of just <>. Not sure how much other people value the
consistency here.


On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson  wrote:

> On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
>  wrote:
> > First of all, why a new keyword? Reusing `for` here would be totally
> > unambiguous. :P And also save us from creating the precedent of
> multi-word
> > keywords.
> >
>
> I'd be equally happy with for instead of forall.
>
> > Secondly, currently Rust has a philosophy of use-follows-declaration
> (i.e.
> > the syntax for using something mirrors the syntax for declaring it). This
> > would eliminate that.
> >
>
> Yes, and I don't have a solution for that.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Benjamin Striegel]

First of all, why a new keyword? Reusing `for` here would be totally
unambiguous. :P And also save us from creating the precedent of multi-word
keywords.

Secondly, currently Rust has a philosophy of use-follows-declaration (i.e.
the syntax for using something mirrors the syntax for declaring it). This
would eliminate that.

Thirdly, I've actually been thinking about something like this for quite a
while. The reason is that our function signatures are LOOONG, and I've
always thought that it would be great to be able to declare the type
parameters above the function, in an attribute or something. But you could
just as easily split after your closing > for the same effect. If people
are fine with ditching use-follows-declaration, then this could be pretty
nice.


On Sat, Feb 1, 2014 at 5:39 PM, Corey Richardson  wrote:

> Hey all,
>
> bjz and I have worked out a nice proposal[0] for a slight syntax
> change, reproduced here. It is a breaking change to the syntax, but it
> is one that I think brings many benefits.
>
> Summary
> ===
>
> Change the following syntax:
>
> ```
> struct Foo { ... }
> impl Trait for Foo { ... }
> fn foo(...) { ... }
> ```
>
> to:
>
> ```
> forall struct Foo { ... }
> forall impl Trait for Foo { ... }
> forall fn foo(...) { ... }
> ```
>
> The Problem
> ===
>
> The immediate, and most pragmatic, problem is that in today's Rust one
> cannot
> easily search for implementations of a trait. Why? `grep 'impl Clone'` is
> itself not sufficient, since many types have parametric polymorphism. Now I
> need to come up with some sort of regex that can handle this. An easy
> first-attempt is `grep 'impl(<.*?>)? Clone'` but that is quite
> inconvenient to
> type and remember. (Here I ignore the issue of tooling, as I do not find
> the
> argument of "But a tool can do it!" valid in language design.)
>
> A deeper, more pedagogical problem, is the mismatch between how `struct
> Foo<...> { ... }` is read and how it is actually treated. The
> straightforward,
> left-to-right reading says "There is a struct Foo which, given the types
> ...
> has the members ...". This might lead one to believe that `Foo` is a single
> type, but it is not. `Foo` (that is, type `Foo` instantiated with type
> `int`) is not the same type as `Foo` (that is, type `Foo`
> instantiated
> with type `uint`). Of course, with a small amount of experience or a very
> simple explanation, that becomes obvious.
>
> Something less obvious is the treatment of functions. What does `fn
> foo<...>(...) { ... }` say? "There is a function foo which, given types ...
> and arguments ..., does the following computation: ..." is not very
> adequate.
> It leads one to believe there is a *single* function `foo`, whereas there
> is
> actually a single `foo` for every substitution of type parameters! This
> also
> holds for implementations (both of traits and of inherent methods).
>
> Another minor problem is that nicely formatting long lists of type
> parameters
> or type parameters with many bounds is difficult.
>
> Proposed Solution
> =
>
> Introduce a new keyword, `forall`. This choice of keyword reads very well
> and
> will not conflict with any identifiers in code which follows the [style
> guide](https://github.com/mozilla/rust/wiki/Note-style-guide).
>
> Change the following declarations from
>
> ```
> struct Foo { ... }
> impl Trait for Foo { ... }
> fn foo(...) { ... }
> ```
>
> to:
>
> ```
> forall struct Foo { ... }
> forall impl Trait for Foo { ... }
> forall fn foo(...) { ... }
> ```
>
> These read very well. "for all types T and U, there is a struct Foo ...",
> "for
> all types T and U, there is a function foo ...", etc. These reflect that
> there
> are in fact multiple functions `foo` and structs `Foo` and implementations
> of
> `Trait`, due to monomorphization.
>
>
> [0]:
> http://cmr.github.io/blog/2014/02/01/polymorphic-declaration-syntax-in-rust/
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Syntax for custom type bounds

[Benjamin Striegel]

> Is using dummy struct fields for specifying custom type bounds on the
struct itself really the best we can do in a brand-new language?

I as well wonder if there's a better way to do this (but I'm note the one
to ask).

> On a slightly different note, is there a strong reason for having to name
lifetime parameters explicitly?

I believe there exist situations where it makes sense for an item to have
multiple lifetime parameters, though I can't think of one off the top of my
head.


On Thu, Jan 30, 2014 at 5:58 PM, Vadim  wrote:

> Just wondering...  Does anyone else feel that "syntax" around lifetimes
> and type bounds is becoming very unwieldy?  I am referring to this PR:
> https://github.com/mozilla/rust/pull/11768.   Is using dummy struct
> fields for specifying custom type bounds on the struct itself really the
> best we can do in a brand-new language?
>
>
> At least for the lifetimes, Rust could extend existing syntax and allow
> specifying them on by-value returns objects, so that, for example, this:
>
> pub trait MutableVector<'a, T> {
> fn mut_iter(self) -> MutItems<'a, T>;
> ...
> }
>
> could be written as:
>
> pub trait MutableVector<'a, T> {
> fn mut_iter(self) -> 'a MutItems;
> ...
> }
>
> This also makes the intent much more clear.   Currently, one would have to
> dig into the definition of MutItems<'a,T> to figure out that the lifetime
> parameter 'a is used to create a dummy borrow field into the vector, so
> that the whole iterator is then treated as a mutable borrow.   This feels
> very convoluted, if you ask me.
>
>
> On a slightly different note, is there a strong reason for having to name
> lifetime parameters explicitly?   Could we simply re-use actual parameter
> names prefixed with ' as their lifetimes?   The above could then be reduced
> to this:
>
> pub trait MutableVector {
> fn mut_iter(self) -> 'self MutItems;
> ...
> }
>
> This used to be valid syntax, btw, though it worked because 'self lifetime
> was special, IIRC.
> Note that I am not proposing to eliminate explicitly named lifetimes
> entirely,- there are still cases when they are needed.  But as far as I've
> seen, those are few and far between.
>
> Thanks for reading,
> Vadim
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "let mut" <-> "var"

[Benjamin Striegel]

> https://github.com/mozilla/rust/issues/2643

I came here to post that link, you beat me to it. :)

Highly, vehemently, frothing-at-the-mouthly against adding `var` as sugar
for `let mut`. You can see from reading that issue that I too was once a
fan of getting rid of `let mut`, but after using Rust in the years since I
can see how lovely the current setup is. I was the one who initiated the
widespread grepping recently that found that `let` was three times more
common than `let mut`, and I admit I was surprised to find that
immutability was so completely dominant. Immutability is crucial to Rust.
Mutability *must* be explicit. Not having to ever worry about
const-correctness is icing on the cake. Adding an alternative form for `let
mut` would go completely against the spirit of the language.


On Thu, Jan 30, 2014 at 12:18 PM, Tim Chevalier wrote:

> I'm surprised that no one has mentioned so far that there was a
> previous, exhaustive, discussion of this question on github:
>
> https://github.com/mozilla/rust/issues/2643
>
> As far as I can tell, this thread adds nothing new that wasn't already
> discussed in the comments on #2643. So that strongly suggests to me
> that nothing needs to be changed.
>
> Cheers,
> Tim
>
>
> On Thu, Jan 30, 2014 at 8:49 AM, Steven Fackler 
> wrote:
> > The Zen of Python also says "There should be one-- and preferably only
> one
> > --obvious way to do it."
> >
> > Steven Fackler
> >
> >
> > On Thu, Jan 30, 2014 at 11:35 AM, Donaldo Fastoso
> >  wrote:
> >>
> >> I like python's rational of "consenting adults": Give people the tools
> >> to do the right thing, if they still want to hurt themselves, they may
> >> have a good reason, or they are better of dead! ;-)
> >>
> >> I would argue, that people choosing Rust over C/C++ are choosing it
> >> BECAUSE of safety measures like immutability and wouldn't need
> >> overbearing lectures.
> >>
> >> In all honesty it's not the TYPING of three additional chars "let mut",
> >> but the READING. It interrupts the flow of reading, or better: it's
> >> a bump in the flow of scanning. Source-Code is not prosa, you have to
> >> actively follow the train of thought and guess the intentions of the
> >> author. So improving READABILITY would really be nice, especially
> >> for people coming from other languages. They would probably try to
> >> learn by reading the source from experienced programmers.
> >>
> >> In this case i would also advice against the use of "var", instead
> >> of "let mut", but omitting "let" and leave it to "mut" would be much
> >> easier to read and understand.
> >>
> >> so
> >> "let mut x, y;"
> >>
> >> would become:
> >>
> >> "mut x;"
> >> "let y;"
> >>
> >> which would take a possible interpretation-ambiguity away from the
> >> single "let mut x, y", which can be read either as "let mut" for x
> >> and y, or "let mut x" and "let y"!
> >>
> >> So imho "let mut" has at least two pitfalls:
> >> 1) read-bump
> >> 2) ambiguity.
> >>
> >> AFAIK you did a remarkable good job so far, and i have all the faith
> >> you are considering all arguments before coming to a decision.
> >>
> >> Even if some thoughts of the thoughts come form the bad smelling
> >> "lurker"-fraction, which do nothing but making comments about things
> they
> >> possible can't understand! ;-)
> >>
> >> Regards,
> >> Don
> >>
> >> ___
> >> Rust-dev mailing list
> >> Rust-dev@mozilla.org
> >> https://mail.mozilla.org/listinfo/rust-dev
> >
> >
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
>
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "If you are silent about your pain, they'll kill you and say you enjoyed
> it."
> -- Zora Neale Hurston
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Benjamin Striegel]

No disrespect intended. Crowdsourced *development* is one of our great
strengths, because things like adding test cases, implementing features,
optimizing benchmarks, reproducing bugs, etc. are all tasks with objective
criteria. When goals are clear, the collective can divide and conquer. But
design and usability are subjective tasks, not objective ones, and instead
of dividing and conquering we merely multiply and surrender.

No one's saying usability can't be discussed. If there are problems, we
DESPERATELY DESPERATELY NEED to be made aware. Even if it's just "the names
of these types confuse me", that's valuable feedback. But belaboring the
point through this many mailing list posts just makes noise and wastes
energy that the full-time devs (note: I am not a full-time dev) can spend
on more valuable tasks.

The other problem with this discussion is that it's premature. We need to
make sure that the new semantics fulfill our criteria of "safe" and
"efficient" before we can commit to the design. If we find problems with
the design, changes may be made that would completely invalidate any
syntactic consensus achieved here.

> 1) X::new() should return an X

The dilemma with making this a rule is that it makes it impossible to ever
construct a structural type (like a tuple) rather than a nominal type. From
an API perspective, a channel is conceptually a pair of two distinct
endpoints, and a tuple fits well. That's not to say that we *have* to use
::new() here: Chan::new() used to just be a free function, stream(), and
had its API changed merely as a part of the last comm rewrite. It could
easily go back to being a free function.

> 2) An "X" should do what it sounds like it does

Agreed, and this is why I don't like Sink or Drain: when I put things down
the sink or in the drain, I generally don't want to ever get them back :)

As for this second point, beware as well that we have many non-native
speakers in this community: idioms that are natural for native English
speakers may not be for them.


On Fri, Jan 24, 2014 at 9:45 AM, Lee Braiden  wrote:

> On 24/01/14 13:34, Benjamin Striegel wrote:
>
>> Anyway, if we've devolving into bikeshedding then it might be time to
>> abandon this thread. Usability isn't something that can be crowdsourced.
>>
>
> Well, what you're essentially saying here (assuming you don't mean to
> disrespect non-core folks by calling them "the crowd") is that "usability
> can't be discussed", but of course it can, IF you bear overall principles
> in mind, rather than devolving into individual instances too much.   In
> this case, the overall usability issues we're TRYING to communicate are:
>
> 1)X::new()  should return an X
> 2)An "X" should do what it sounds like it does
>
>
>
> --
> Lee
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Benjamin Striegel]

> Channel should be a struct

This is feasible:

let Chan { send, recv } = Chan::new();

...but it seems needlessly verbose, given that literally 100% of the time
you will want to separate the sending end from the receiving end. It makes
no conceptual sense to have a `Chan` as a discrete entity, when it's
effectively just an abstraction for two entangled endpoints.

Anyway, if we've devolving into bikeshedding then it might be time to
abandon this thread. Usability isn't something that can be crowdsourced.


On Fri, Jan 24, 2014 at 7:23 AM, Lee Braiden  wrote:

>  On 24/01/14 03:54, Brandon Sanderson wrote:
>
> I would expect Channel::new() to create a channel object that either lets
> me send and receive, or lets me get a source and sink to send and receive
> with.  Borrow rules may prevent this, but my point is that Channel::new()
> would generally be expected to return a struct, and not a tuple.
>
>
> Yes.  I think either:
>
> * Channel should be a struct, created by Channel::new(), with sender
> and receiver instances as fields (by whatever name) -- essentially, the
> tuple should become a struct, with better naming of port and chan
> * Channel should have a  ChannelTrait implemention, with send() and
> receive(), and should be created by Channel::new()
>
> But from what Benjamin says below, it seems like the latter isn't
> necessary.
>
>
>  On Jan 23, 2014 7:29 PM, "Benjamin Striegel" 
> wrote:
>
>>  This all seems a bit silly. A channel *is*, conceptually, a tuple of a
>> sender and a receiver. If I call Chan::new(), that's what I expect to get.
>> And Chan::open() doesn't map to anything that's as intuitive.
>>
>
> --
> Lee
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Benjamin Striegel]

If we're going to quibble over names we might as well call the types Sender
and Receiver.

Really though, EVERYONE is fine with the proposed semantics from the
original thread? Really? Speak up if you have anything valuable to add that
isn't bikeshedding! :)


On Thu, Jan 23, 2014 at 11:13 PM, don  wrote:

> Hi, as a not contributing listen-in,
>
> i would like to voice that source and sink share the same initial and
> therefore source and drain might be more useful.
>
> I hope i didn't offend by voicing my opinion,
> keep up the good work!
>
> Regards Don
>
>
> Am 24.01.2014 04:54, schrieb Brandon Sanderson:
>
>> I would expect Channel::new() to create a channel object that either
>> lets me send and receive, or lets me get a source and sink to send and
>> receive with.  Borrow rules may prevent this, but my point is that
>> Channel::new() would generally be expected to return a struct, and not a
>> tuple.
>>
>> On Jan 23, 2014 7:29 PM, "Benjamin Striegel" > <mailto:ben.strie...@gmail.com>> wrote:
>>
>> This all seems a bit silly. A channel *is*, conceptually, a tuple of
>> a sender and a receiver. If I call Chan::new(), that's what I expect
>> to get. And Chan::open() doesn't map to anything that's as intuitive.
>>
>> Is naming really all that's left to argue about? How does everyone
>> feel about the semantics of the proposal?
>>
>>
>> On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic
>> mailto:v...@markovic.io>> wrote:
>>
>>
>> On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri
>> mailto:basc...@gmail.com>> wrote:
>>
>> I have a crazy idea...
>>
>> Channel::open()
>>
>>
>> That's a better name for the function, agreed.
>>
>>
>> https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/
>> B_0/0Vc8_mnnhqw/s1600/mind-blown.gif
>>
>> --
>> Tony Arcieri
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
>>
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
>>
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>  ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Benjamin Striegel]

This all seems a bit silly. A channel *is*, conceptually, a tuple of a
sender and a receiver. If I call Chan::new(), that's what I expect to get.
And Chan::open() doesn't map to anything that's as intuitive.

Is naming really all that's left to argue about? How does everyone feel
about the semantics of the proposal?


On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic wrote:

>
> On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri  wrote:
>
>> I have a crazy idea...
>>
>> Channel::open()
>>
>
> That's a better name for the function, agreed.
>
>
>>
>>
>> https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif
>>
>> --
>> Tony Arcieri
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust 0.9 released

[Benjamin Striegel]

Congrats everyone! Here's to 0.10. :)


On Thu, Jan 9, 2014 at 4:04 PM, Brian Anderson wrote:

>  Mozilla and the Rust community are pleased to announce version 0.9 of the
> Rust compiler and tools. Rust is a systems programming language with a
> focus on safety, performance and concurrency.
>
> This was another eventful release in which we made extensive improvements
> to the runtime and I/O subsystem, introduced static linking and link-time
> optimization, and reduced the variety of closures in the language. 0.9
> also
> begins a final series of planned changes to how pointers are treated in
> Rust, starting with the deprecation of the built-in "managed pointer" type
> and its accompanying `@` sigil, and the introduction of smart pointer
> types
> to the standard library.
>
> The brief release notes are included in this announcement, and there is
> further explanation in the detailed release [notes] on the wiki.
> Documentation and all the links in this email are available on the
> [website]. As usual, version 0.9 should be considered an alpha release,
> suitable for early adopters and language enthusiasts. Please file [bugs]
> and join the [fun].
>
> [website]: http://www.rust-lang.org
> [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes
> [bugs]: https://github.com/mozilla/rust/issues
> [fun]:
> https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors
>
> This release is available as both a tarball and a Windows installer:
>
> * http://static.rust-lang.org/dist/rust-0.9.tar.gz
> http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc
> SHA256 (of .tar.gz):
> c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1
>
> * http://static.rust-lang.org/dist/rust-0.9-install.exe
> http://static.rust-lang.org/dist/rust-0.9-install.exe.asc
> SHA256 (of .exe):
> 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90
>
> Thanks to everyone who contributed!
>
> Regards,
> The Rust Team
>
>
> Version 0.9 (January 2014)
> --
>
> * Language
> * The `float` type has been removed. Use `f32` or `f64` instead.
> * A new facility for enabling experimental features (feature gating)
> has been added, using the crate-level `#[feature(foo)]` attribute.
> * Managed boxes (@) are now behind a feature gate
> (`#[feature(managed_boxes)]`) in preperation for future removal. Use
> the standard library's `Gc` or `Rc` types instead.
> * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead.
> * Jumping back to the top of a loop is now done with `continue` instead
> of `loop`.
> * Strings can no longer be mutated through index assignment.
> * Raw strings can be created via the basic `r"foo"` syntax or with
> matched hash delimiters, as in `r###"foo"###`.
> * `~fn` is now written `proc (args) -> retval { ... }` and may only be
> called once.
> * The `&fn` type is now written `|args| -> ret` to match the literal
> form.
> * `@fn`s have been removed.
> * `do` only works with procs in order to make it obvious what the cost
> of `do` is.
> * Single-element tuple-like structs can no longer be dereferenced to
> obtain the inner value. A more comprehensive solution for overloading
> the dereference operator will be provided in the future.
> * The `#[link(...)]` attribute has been replaced with
> `#[crate_id = "name#vers"]`.
> * Empty `impl`s must be terminated with empty braces and may not be
> terminated with a semicolon.
> * Keywords are no longer allowed as lifetime names; the `self` lifetime
> no longer has any special meaning.
> * The old `fmt!` string formatting macro has been removed.
> * `printf!` and `printfln!` (old-style formatting) removed in favor of
> `print!` and `println!`.
> * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`.
> * The `extern mod foo (name = "bar")` syntax has been removed. Use
> `extern mod foo = "bar"` instead.
> * New reserved keywords: `alignof`, `offsetof`, `sizeof`.
> * Macros can have attributes.
> * Macros can expand to items with attributes.
> * Macros can expand to multiple items.
> * The `asm!` macro is feature-gated (`#[feature(asm)]`).
> * Comments may be nested.
> * Values automatically coerce to trait objects they implement, without
> an explicit `as`.
> * Enum discriminants are no longer an entire word but as small as needed
> to contain all the variants. The `repr` attribute can be used to
> override the discriminant size, as in `#[repr(int)]` for integer-sized,
> and `#[repr(C)]` to match C enums.
> * Non-string literals are not allowed in attributes (they never worked).
> * The FFI now supports variadic functions.
> * Octal numeric literals, as in `0o`.
> * The `concat!` syntax extension performs compile-time string
> concatenation.
> * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been
> removed as Rust no longer uses segmented stacks.
> * Non-ascii identifiers are feature-gated
> (`#[feature(non_ascii_idents)]`).
> * Ignoring all fields of an enum variant or tuple-struc

Re: [rust-dev] Emscripten for Rust?

[Benjamin Striegel]

I'm not sure if this is generally feasible! If memory-unsafe C/C++ code
could be automatically and mechanically converted to memory-safe Rust code,
then that would imply the existence of static analysis tools for C/C++ code
that could themselves guarantee memory safety without requiring Rust at all.


On Sun, Jan 5, 2014 at 9:11 PM, Greg  wrote:

> I'd happy chip in for a Kickstarter-type project to automatically convert
> C/C++ to Rust.
>
> Anything like this exists or anyone planning on making this type of
> announcement?
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Generalized monadic notation

[Benjamin Striegel]

Every time that we've added magic, we've lived to regret it and ultimately
revert it. If there exists only a single lesson of the past few years of
language evolution, let it be this.

Furthermore, any discussions of monads and/or HKT are pie-in-the-sky at
this point. Our complexity budget is stretched thin enough as it is. Assume
that Rust 1.0 will *not* have these features, and plan accordingly.


On Tue, Dec 24, 2013 at 12:09 PM, Daniel Micay wrote:

> On Tue, Dec 24, 2013 at 11:23 AM, Bill Myers 
> wrote:
> > Some languages support a special "do notation" that allows to express
> monadic operations more naturally.
> >
> > However, there is an even more powerful option, that I'd call "in
> notation" (I came up with it, but it's obvious, so I'm sure there's some
> language that has something like it).
> >
> > The idea is that we add an "in" keyword, and in-types, which are the
> type "in T" where T is a monadic type.
> >
> > In-types are physically represented as the monadic type, but
> semantically behave like the type contained in the monad; they are
> constructed with the expression "in x".
> >
> > The "out" keyword does the opposite, converting an in-type to the
> wrapped type.
> >
> > Operations performed on in types actually act on the value inside of the
> monad, as better specified below
> >
> > Quick examples:
> > out(in Some(3) + 6) gives Some(9)
> > out(in Some(3) + in Some(6)) also gives Some(9)
> > out(in Some(3) + in None) gives None
> > out(in ~[1, 2, 3] + 10) gives ~[11, 12, 13]
> > out(in ~[1, 2, 3] + in ~[10, 20, 30]) gives ~[11, 21, 31, 12, 22, 32,
> 13, 23, 33]
> >
> > Internally, when the compiler encounters any expression including an
> in-type (expressions include control flow constructs), it proceeds like
> this (considering its operands from left to right):
> > 1. Optionally, if the expression is correctly typed (e.g. calling a
> function that takes an in-type), it compiles it normally
> > 2. If the expression does not have an in-type value itself, it converts
> the expression into a closure, and passes it to map()
> > 2. If the expression does have an in-type value itself (for example in x
> + in y has an in-type when viewed as a function of in x, due to the
> presence of in y), it converts out(expression) into a closure, and passes
> it to flat_map()
> >
> > Non-movable control flow like return or break is forbidden in expression
> involving in-types (they can be implemented with a flag, but that causes
> other equivalence issues).
> >
> > The advantage of this is that special do-notation syntax is not
> required, and one can naturally manipulate the values.
> >
> > The disadvantage is that it adds a layer of "magic", making what the
> code actually does less obvious.
> >
> > This is particularly true with list-like monads, where simple things
> like (in x) + (in y) actually become a double loop with quadratic run-time;
> this can be optionally avoided by only allowing "in notation" to be used
> with monads that call the closure once.
> >
> > Also, side effects will be performed a different amount of times
> depending on the monad values, which may also not be obvious.
> >
> > Note that there are a lot of details that I omitted for the sake of
> brevity, and would need to be handled.
>
> I'm strongly against adding complex language features like this.
> Parser expansion hacks or complex fallback paths have no place in the
> language proper. The pattern should be possible to encode in traits
> and needs to be proven as a widely applicable form of code reuse with
> an insignificant cognitive and performance overhead before discussing
> syntactic sugar makes sense.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

[Benjamin Striegel]

> For those of us that were not around or do not remember, can you explain
what was tried and rejected?

Heh, it was so long ago that I forgot that the `match` keyword used to be
`alt`. Here's the relevant section from the 0.1 manual (Jan 2012):

https://github.com/mozilla/rust/blob/16e4369fe3b5f00aa3cdc584a4e41c51c0d3ca8a/doc/tutorial.md#pattern-matching

"If the arm with the wildcard pattern was left off in the above example,
running it on a number greater than ten (or negative) would cause a
run-time failure. When no arm matches, alt constructs do not silently fall
through—they blow up instead."

Back then, we had no facility to statically force exhaustiveness. This
changed in 0.2, when exhaustive matches became the default, though you
could still opt-in to non-exhaustive matches by using `alt check` rather
than `alt`.

https://github.com/mozilla/rust/blob/619c4fce891f31ec234a3ac162d40d3def95956e/RELEASES.txt#L581

Indeed, as you mention, at the time people were worried that this would
lead to widespread proliferation of `_ => fail`, especially for uses such
as matching on integers, which we lack the facilities to exhaustively
check. However, in the years since, I can remember only a single person
noticing this and lamenting it, and the peace of mind provided by
statically-checked exhaustiveness is certainly pleasant. Furthermore, so
few people opted-in to dynamic checking via `alt check` that we had dropped
the functionality entirely by 0.4.


On Mon, Dec 23, 2013 at 3:40 PM, Simon Sapin  wrote:

> On 23/12/2013 20:55, Benjamin Striegel wrote:
>
>> I too think it would be a big mistake to allow let patterns to be
>> refutable, when we've already tried and rejected allowing the same in
>> match statements (ancient Rust history quiz: who else remembers `match
>> check`?).
>>
>
> For those of us that were not around or do not remember, can you explain
> what was tried and rejected?
>
> I sometimes find myself writing a `_ => ()` arm for match and wish it
> could be implied… and sometimes `_ => fail!()`. That the two are sometimes
> used is probably a sign that the status quo (require it to be explicit) is
> better.
>
> --
> Simon Sapin
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

[Benjamin Striegel]

I too think it would be a big mistake to allow let patterns to be
refutable, when we've already tried and rejected allowing the same in match
statements (ancient Rust history quiz: who else remembers `match check`?).


On Mon, Dec 23, 2013 at 2:44 PM, Gábor Lehel  wrote:

> That seems like a nice compromise, but I don't think it's a good one.
> Either you intended the pattern to be refutable or you didn't. If you
> didn't and it is, you should get an error, not a warning. If you did, you
> shouldn't get a warning at all. Are you going to put a compiler pragma to
> disable the warning at every use site where you intentionally want a let to
> be refutable? At that point, you might as well have separate syntax for
> refutable and irrefutable lets. Or are you just going to live with having
> false positive warnings in your code?
>
> (FWIW, I'm basically fine with having only irrefutable lets, and using
> `match` for the other cases, or in other words the status quo. But if we
> *do* add refutable lets, I strongly think they should be explicit.)
>
>
>
> On Mon, Dec 23, 2013 at 7:03 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> that seems like a reasonable balance
>>
>>
>> On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton wrote:
>>
>>> On 12/23/13 4:12 AM, Gábor Lehel wrote:
>>>
 I don't like either that (a) the possible failure is silent, and
 refutable lets look the same as irrefutable ones, nor (b) baking fail!()
 into the semantics. Haskell has these also and I think it's a wart. The
 proposed syntax solves both issues.

>>>
>>> For what it's worth, Rust's pattern matching is pretty heavily based on
>>> OCaml's and the OCaml compiler complains with a warning if you use a
>>> refutable pattern in `let`.
>>>
>>
>>> Patrick
>>>
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

[Benjamin Striegel]

> the OCaml compiler complains with a warning if you use a refutable
pattern in `let`.

And what does OCaml do at runtime if the pattern is refuted?


On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton wrote:

> On 12/23/13 4:12 AM, Gábor Lehel wrote:
>
>> I don't like either that (a) the possible failure is silent, and
>> refutable lets look the same as irrefutable ones, nor (b) baking fail!()
>> into the semantics. Haskell has these also and I think it's a wart. The
>> proposed syntax solves both issues.
>>
>
> For what it's worth, Rust's pattern matching is pretty heavily based on
> OCaml's and the OCaml compiler complains with a warning if you use a
> refutable pattern in `let`.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Joe Armstrong's "universal server"

[Benjamin Striegel]

Hello rusties, I was reading a blog post by Joe Armstrong recently in which
he shows off his favorite tiny Erlang program, called the Universal Server:

http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html

I know that Rust doesn't have quite the same task communication primitives
as Erlang, but I'd be interested to see what the Rust equivalent of this
program would look like if anyone's up to the task of translating it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Interesting talk about (scala) language/compiler complexity

[Benjamin Striegel]

> 3. *Using inheritance for collection mutability is bad.* Rust doesn't do
it.

Is this an argument against generalizing over mutability at all (as I
believe has been proposed in the past)?


On Wed, Dec 4, 2013 at 10:53 PM, Patrick Walton wrote:

> On 12/4/13 5:07 PM, Ziad Hatahet wrote:
>
>> To be taken with a grain of salt, naturally:
>> https://www.youtube.com/watch?v=TS1lpKBMkgg
>>
>
> I watched some of this. Some notes on specific criticisms follow. (Many of
> the criticisms are too abstract to really confront head-on though--for
> example, "correctness versus performance".)
>
> 1. *The compiler is too hard to modify.* See my other message in the
> thread.
>
> 2. *Universal equality is bad.* Rust doesn't do it.
>
> 3. *Using inheritance for collection mutability is bad.* Rust doesn't do
> it.
>
> 4. *The argument to functions such as "filter" should be pure to allow for
> stream fusion.* Purity is hard in Rust. We tried it and the annotation
> burden was too high. At least our iterators allow for more stream fusion
> than creating intermediate data structures would.
>
> 5. *Forbid reference equality.* Incompatible with the systems language
> nature of Rust.
>
> 6. *Silent coercion between primitives is bad.* Rust doesn't do it.
>
> 7. *Don't try to be too general purpose.* Rust is explicitly not designed
> to be a language for all use cases.
>
> 8. *Unnecessary expressiveness is the enemy.* I think we've been holding
> the line on language complexity quite well, even for features that are
> popular like `&once fn`.
>
>
> Patrick
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please welcome the Rust and Servo GNOME/OPW interns for December 2013-March 2014

[Benjamin Striegel]

Hooray, welcome to our new contributors! :) And thanks to our mentors and
coordinators as well!


On Wed, Dec 4, 2013 at 11:18 AM, Tim Chevalier wrote:

> Hello,
>
> I'm pleased to announce that the winter/spring Rust and Servo interns
> through the GNOME Outreach Program for Women (
> https://wiki.gnome.org/OutreachProgramForWomen ) have been chosen. The
> program starts December 10 and runs until March 10.
>
> Nif Ward (IRC nick: nif) will be interning on Rust, working to develop
> a full-fledged B-tree library. Nif is a senior graduating this fall in
> computer science from Oberlin College in Ohio, USA. I will be her
> mentor.
>
> Isabelle Carter (IRC nick: ibnc) will be interning on Servo, working
> to add support for fixed positioning. Isabelle is on leave from her
> undergraduate degree in mathematics, and will be working from
> Springfield, Missouri, USA. Lars Bergstrom will be her mentor.
>
> We had many qualified applicants for Rust and Servo's first foray into
> OPW, so it's an honor to be chosen for this program. Please be
> friendly to nif and ibnc if you see them on #rust!
>
> Depending how this round of OPW goes, Rust and/or Servo may
> participate in a future iteration, so if you're interested in
> applying, then keep watching for more announcements. In addition,
> internships at Mozilla working on Rust and Servo (look for the
> "Research Engineering" listing; paid, on-site in the Bay Area) are
> open to all graduate students (undergraduate students with research
> experience have been considered in the past):
> http://careers.mozilla.org/ .
>
> Thanks are due to the Rust and Servo teams -- particularly Lars
> Bergstrom, Brian Anderson, and Jack Moffitt -- for helping many people
> apply for the program, and to the Mozilla coordinator for OPW, Larissa
> Shapiro, for their efforts.
>
> Cheers,
> Tim
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "If you are silent about your pain, they'll kill you and say you enjoyed
> it."
> -- Zora Neale Hurston
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] How to search the mailing list archives

[Benjamin Striegel]

Apparently even Brian doesn't know how to do this, so I figured I'd share
this tip.

The rust-dev mailing list is archived here:

http://thread.gmane.org/gmane.comp.lang.rust.devel/

Use the search box at the bottom to search through the mailing list's
archives since the beginning of time.

When you click on a result, you will end up on a page like this:

http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst

...which is pretty terrible from a navigation standpoint. But in that URL
you can manually change the "article" bit on the front to "thread", to
yield this:

http://thread.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst

...which will let you easily browse a full conversation.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust front-end to GCC

[Benjamin Striegel]

This is very cool! But, I agree with Daniel. If there's any way that we can
reduce the duplication of effort, we should. This is especially true given
that we don't have anything close to an accurate written specification to
help keep two implementations in sync.


On Tue, Dec 3, 2013 at 12:54 PM, Daniel Micay  wrote:

> On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron 
> wrote:
> > Hey all
> >
> > Some of you may have noticed the gccrs branch on the git mirror. Since
> PyCon
> > IE 2013 i gave a talk on my Python Front-end pet project and heard about
> > rust by a few people and i never really looked at it before until then
> but
> > i've kind of been hooked since.
> >
> > So to learn the language i've been writing this front-end to GCC. Only
> > really a a month or  so on and off work in between work. Currently it
> > compiles alot of rust already in fairly little effort on my side GCC is
> > doing loads of the heavy lifting.
> >
> > Currently it compiles most of the basic stuff such as a struct an impl
> block
> > while loop, functions expressions calling methods passing arguments etc.
> > Currently focusing on getting the typing working correctly to support &
> and
> > ~ and look at how templates might work as well as need to implement break
> > and return.
> >
> > There is still a lot of work but i would really like to share it and see
> > what people think. Personally i think rust will target GCC very well and
> be
> > a good addition (if / when it works). I really want to try and give back
> to
> > this community who have been very good to me in learning over the last
> few
> > years with GSOC.
> >
> > To get a jist of what i am compiling in my tests are something like:
> >
> > fn fib1 (n:int) -> int {
> > if (n <= 1) { 1 }
> > else { n * fib1 (n - 1) }
> > }
> >
> > fn fib2 (n:int) -> int {
> > let mut i = 1;
> > let mut result = 1;
> > while (i <= n) {
> > result = result * i;
> > i = i + 1;
> > }
> > result
> > }
> >
> > fn main () {
> > fib1 (10);
> > fib2 (10);
> > }
> >
> > Or
> >
> > struct mytype {
> > x : int
> > }
> >
> > impl mytype {
> > fn test (self) -> int {
> > println ("yyoyoyo");
> > test2 (1)
> > }
> > }
> >
> > fn main () {
> > let x = mytype { x : 1 };
> > let z = x.x;
> > let y = x.test ();
> > let a = test2 (y);
> > }
> >
> > fn test2 (x : int) -> int {
> > let z = x;
> > 1 + z
> > }
> >
> > Theses are both pretty abstract test cases but were the ones i just made
> > work a while ago. Lots more work to do on it but i feel these 2 test
> cases
> > working is kind of a mile stone for me.
> >
> > I will start a wiki page on the project and the code i work on is at
> > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i
> have
> > it on github first mostly for travis CI and so i can do a bunch of
> commits
> > and rebase etc http://github.com/redbrain/gccrs
> >
> > Thanks
> >
> > --Phil
>
> I think another backend would be very valuable, but not another
> implementation of the rest of the compiler. I would expect a gcc
> backend to be based on libsyntax/librustc with an alternate backend
> for `trans` and `back`.
>
> Implementing a fully compatible compiler with a full parser/macros,
> metadata, type-checking, borrow checking, liveness checking, type
> inference, privacy/reachability, etc. doesn't seem feasible. The
> upstream compiler already has hundreds of issues to fix in these
> areas.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Placement new and the loss of `new` to keywords

[Benjamin Striegel]

If `expr @ place` suffices then you'd think that re-using `in` keyword as
per `expr in place` would also work, but I believe we rejected that for
technical reasons in past discussions. And if those technical reasons no
longer apply, I'd like to motion that `in` looks way better than `@` there.
:)


On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister <
michaelwoeris...@posteo.de> wrote:

> +1 for `expr @ place`
>
>
> On 02.12.2013 11:57, Kevin Ballard wrote:
>
>> With @ going away another possibility is to leave ~ as the normal
>> allocation operator and to use @ as the placement operator. So ~expr stays
>> the same and placement looks either like `@place expr` or `expr@place`
>>
>> -Kevin Ballard
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust forum

[Benjamin Striegel]

> The idea of an online user forum would be that people with an interest in
Rust can read in the user forum which is easier to peruse than some mail
list archive. Asking and getting answers seems to work more fluently.

I agree with the principle, but we have yet to identify what users would
actually want to peruse in a discussion forum. For questions, we have
StackOverflow. For keeping up with the cool projects that the community is
working on, we have reddit. Piggybacking on established platforms will lead
to easier discoverability and broader readership.

Which isn't to say that a discussion forum won't be warranted sometime in
the future, but for now we're getting along quite well with the free
alternatives provided by the broader web.


On Tue, Dec 3, 2013 at 3:43 AM,  wrote:

>  The idea of an online user forum would be that people with an interest
> in Rust can read in the user forum which is easier to peruse than some mail
> list archive. Asking and getting answers seems to work more fluently.
>
> There is really hell going on on the Go users forum:
> https://groups.google.com/forum/?hl=de#!forum/golang-nuts An online forum
> seems to intensivy people's interest in some language. But it's certainly
> your language and your decision what you want to do.
>
> Regards, Oliver
>
> *Gesendet:* Dienstag, 03. Dezember 2013 um 07:35 Uhr
> *Von:* "Eric Reed" 
> *An:* "David Piepgrass" 
> *Cc:* "rust-dev@mozilla.org" 
> *Betreff:* Re: [rust-dev] Rust forum
>  Well there's always r/rust/ . It usually
> works pretty well.
>
> On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass wrote:
>>
>>  On 02/12/2013 16:21, David Piepgrass wrote:
>>
>>> > That would be so. much. better. than a mailing list.
>>>
>>> Hi. Could you expand on this? I don?t necessarily disagree, but as the
>>> one proposing change it?s up to you to convince everyone else :)
>>>
>>> --
>>> Simon Sapin
>>
>>
>> Okay, well, I've never liked mailing lists at all, because:
>>
>> 1. In non-digest mode, My inbox gets flooded.
>> 2. In digest mode, it's quite inconvenient to write a reply, having to
>> cut out all the messages that I don't want to reply to and manually edit
>> the subject line. Also, unrelated messages are grouped together while
>> threads are broken apart, making discussions harder to follow.
>> 3. In email I don't get a threaded view. If I go to mailing list archives
>> to see a threaded view, I can't reply.
>> 4. I have to manually watch for replies to my messages or to threads I'm
>> following. If someone mentions my name (not that they would), I won't be
>> notified.
>>
>>  In contrast, Discourse has a variety of email notification options. I
>> don't know if those options are enough to please everybody, but you can
>> probably configure it to notify you about all posts, which makes it
>> essentially equivalent to a mailing list. It supports reply by email, so
>> those that prefer a mailing list can still pretend it's a mailing list.
>> Currently I'm getting an shrunk digest of Discourse Meta--by email I only
>> get a subset of all messages, auto-selected by Discourse, whatever it
>> thinks is interesting. That's good for me: I really don't want to see every
>> message.
>>
>> Plus, a mailing list offers less privacy as it mandates publishing your
>> email address. That's not a big deal for me personally, but do you really
>> want to require that from every Rust user?
>>
>>  (btw, if I'm wrong about any of the above points, I promise there are
>> lots of other netizens out there who have the same misconception(s), so
>> many of them will avoid mailing lists. The fact that y'all are talking to
>> me on a mailing list suggests that the disadvantages of a mailing list are
>> not a big deal *to you*, but as for those who aren't participating, you
>> can't conclude *they* prefer mailing lists.)
>>
>>  And like mailing lists, Discourse also supports private messages.
>>
>> I don't understand why Paul mentioned GPG. You want to encrypt messages
>> to a public mailing list? You can sign messages, but surely almost no one
>> actually checks the signature, and I'd be surprised if Discourse didn't
>> offer some built-in evidence of identity (surely it's not like email in
>> letting you spoof the sender name easily?).
>>
>> I heard discourse supports attachments, just that you may have to go to
>> the forum to attach or download them (rather than by email).
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust forum

[Benjamin Striegel]

I'm not sure that discussion forums are the best alternative to the typical
"foo-users" mailing list. Topics are generally less about discussion and
more about getting a quick answer to a problem; IRC is okay for this at the
moment, but once Rust stabilizes I'd much prefer just using StackOverflow
to host these sorts of questions.

(For the moment, however, asking questions on SO just makes more work for
us once the language actually does stabilize, since we'll need to go
through and make sure all the answers are still relevant.)

It's also not like this is an exclusive choice. We could have a rust-users
list as well as a discussion forum. It's just that we'd need to figure out
what to actually use the forum for that other outlets don't already do well
(e.g. reddit.com/r/rust is a pretty good link aggregator).


On Mon, Dec 2, 2013 at 11:21 AM, David Piepgrass wrote:

> Hey, why not set up a Discourse forum? That would be so. much. better.
> than a mailing list. As an OSS dev I've been itching to get one myself, but
> don't have time or much money to set it up. For Mozilla, though? No problem
> I'm sure.
>
> http://www.discourse.org/
> Google: discourse hosting.
> http://www.google.com/search?q=discourse+hosting
>
>
> From: Eric Reed 
>> ...
>> I'm not aware of any plans for a rust-users forum. Maybe spinning a
>> rust-users mailing list off from rust-dev would make sense? We already did
>> a similar thing with our IRC channels.
>>
>>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Placement new and the loss of `new` to keywords

[Benjamin Striegel]

Eh, I'm as fine with `box` as I am with `new`. Does seem a bit like jargon,
though. Though maybe it will herald a return to the days when we really
played up the "shipping container" flavor. Crates and cargo, anyone? :)


On Sun, Dec 1, 2013 at 12:42 AM, Patrick Walton wrote:

> On 11/30/13 6:49 PM, Corey Richardson wrote:
>
>> On Sat, Nov 30, 2013 at 9:30 PM, Kevin Ballard  wrote:
>>
>>> I'm still very much a fan of leaving ~ as the allocation operator.
>>> Despite what Patrick says, I'm pretty sure the reason why users are
>>> confused about it is purely due to sub-par documentation, and not due to
>>> any actual inherent problems with using a non-alphabetic symbol as an
>>> operator. Heck, we have plenty of other non-alphabetic operators that don't
>>> cause confusion, why is this one special?
>>>
>>>
>> I'll admit, I don't find the "confusing" argument very convincing. I
>> just think `box` looks better than `~`.
>>
>
> I'm warming up to this idea -- `box 10` does make more sense than `new 10`.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Placement new and the loss of `new` to keywords

[Benjamin Striegel]

> The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that.

I much prefer `new` to `alloc`. It *is* a shame that `foo::new()` has to
change, but `alloc` is much grosser than `init`. And maybe we can think of
a better naming convention for constructors... perhaps `foo::make()`.

Honestly, `new` seems ideal here. Easier to type than `~` and easier on the
eyes than `alloc`. The only argument that I can think of against it would
be if its semantics are different enough from C++ that it would cause more
confusion than it alleviates.


On Sat, Nov 30, 2013 at 4:54 PM, Patrick Walton wrote:

> On 11/30/13 1:24 AM, Kevin Ballard wrote:
>
>> Speaking of `new (x + y)`, has any thought been given to
>>
> differentiating `new (expr)` from placement-new?
>
> Yeah, this came up. We can just define new followed by `(` to resolve in
> favor of placement new.
>
>
>  Given all this, my inclination at this point is to say that trying
>> to
>>
> piggyback on C++ programmers' familiarity of `new` is actually a really
> bad idea, as Rust's allocation operator differs in a few important ways
> from C++. In fact, offhand I can't think of any language with a `new
> `operator that uses it for something other than invoking a class
> constructor.
>
> Well, there aren't many languages with allocation operators period: the
> vast majority of languages implicitly allocate on the heap. Of those
> languages with an allocation operator that isn't a function, it's
> universally `new` as far as I know.
>
> The other suggestion that's been floated that satisfies all of these
> constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
> should just switch to that. It's not that I'm unconcerned about `new()(1 +
> 2)` being weird: it's that I'm more concerned about what's not going to
> make C++ programmers run away.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Ideas of small projects or improvements

[Benjamin Striegel]

It's okay, it's our own fault for not having yet written a document
entitled "Things That Absolutely Will Not Change And That We Are Tired Of
Discussing." :P


On Sat, Nov 30, 2013 at 4:34 PM, Gaetan  wrote:

> Sorry for this offtopic subject..
> Le 30 nov. 2013 20:20, "Benjamin Striegel"  a
> écrit :
>
>  > Is is possible to get rid of this returnless return?
>> > I mean, it is really hard yo read, why not enforcing the use of return
>> statement, always?
>>
>> This isn't the point of this thread, and also I don't think anybody is
>> willing to revisit this issue. Consider that ship as having sailed beyond
>> the horizon.
>>
>>
>> On Sat, Nov 30, 2013 at 2:17 PM, Gaetan  wrote:
>>
>>> Is is possible to get rid of this returnless return?
>>>
>>> I mean, it is really hard yo read, why not enforcing the use of return
>>> statement, always?
>>> Le 30 nov. 2013 19:59, "György Andrasek"  a écrit :
>>>
>>> On 11/30/2013 07:41 PM, Pierre Talbot wrote:
>>>>
>>>>> Do you have suggestions that could fit well for this kind of project?
>>>>>
>>>>
>>>> Make the following code compile:
>>>>
>>>> ```
>>>> fn foo() {
>>>>   bar()
>>>>   fn bar() {}
>>>> }
>>>> ```
>>>>
>>>> i.e. allow nested function declarations after a semicolonless return
>>>> expression.
>>>> ___
>>>> Rust-dev mailing list
>>>> Rust-dev@mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] do

[Benjamin Striegel]

> (I forget the name, sadly)

This is usually referred to as Tennet's Correspondence Principle:

http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html

...though it is sometimes debated whether or not the modern interpretation
of this principle is actually what Tennet intended (the book in which it
appeared is apparently quite hard to get a hold of).


On Sat, Nov 30, 2013 at 2:40 PM, Kevin Ballard  wrote:

> On Nov 30, 2013, at 10:20 AM, Patrick Walton  wrote:
>
> > On 11/30/13 10:05 AM, Kevin Cantu wrote:
> >> While we're changing this stuff, I'd like to see lambdas allow return,
> >> now that the need for forbidding that is gone, IIRC.  That's more likely
> >> to continually trip me up than unusual allocation mechanisms.
> >
> > No objections here.
>
> Quite a while ago the restriction on `return` was explained to me as
> conforming to some principle (I forget the name, sadly) that basically says
> that wrapping a block of code in a closure and immediately calling the
> closure should not change the semantics of the code. Basically, `return`
> shouldn't return from the lambda because that's not what it would do if the
> closure was inlined manually.
>
> I didn't really understand the point of this, of course.
>
> -Kevin
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Ideas of small projects or improvements

[Benjamin Striegel]

Currently our `for` loops are implemented strangely. In essence, right now
a `for` loop is just syntax sugar that gets expanded during the parsing
stage. This was easy to implement, but it means that our error messages
around `for` loops are strange and it limits our ability to do more
intelligent things, like so:

for i in [1,2,3] {  // currently we can't do this, you need to write
out `[1,2,3].iter()`

If you could implement `for` loops in the "proper" way, it would be a great
boon to us. However, I'm not the one who really knows exactly what the
"proper" way is. :) And I wasn't able to find an issue in the bug tracker
for this with any details. Perhaps Daniel Micay (strcat) could elaborate.


On Sat, Nov 30, 2013 at 1:41 PM, Pierre Talbot  wrote:

> Hello folks,
>
> I'm a French student finishing his study this year and a teacher gave us a
> project to finish by the end of the year which is to modify (or add) a
> small feature to an existing interpreter (or compiler, language,...) such
> as a primitive or a control structure.
> I'm pretty new to Rust and I wonder if you have some ideas, some works
> that could possibly be useful to Rust, even if extremely small. My
> objective is to get into Rust with this homework and then work further on
> Rust later.
> I can guess how much is hard to understand a compiler and start working on
> it, and that's basically why I'm asking you for an idea. I already worked
> on open-source projects (mainly in C++) so I don't have much "outside
> lessons" to take (such as learning git).
>
> Do you have suggestions that could fit well for this kind of project?
>
> Best regards,
> Pierre Talbot.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Ideas of small projects or improvements

[Benjamin Striegel]

> Is is possible to get rid of this returnless return?
> I mean, it is really hard yo read, why not enforcing the use of return
statement, always?

This isn't the point of this thread, and also I don't think anybody is
willing to revisit this issue. Consider that ship as having sailed beyond
the horizon.


On Sat, Nov 30, 2013 at 2:17 PM, Gaetan  wrote:

> Is is possible to get rid of this returnless return?
>
> I mean, it is really hard yo read, why not enforcing the use of return
> statement, always?
> Le 30 nov. 2013 19:59, "György Andrasek"  a écrit :
>
> On 11/30/2013 07:41 PM, Pierre Talbot wrote:
>>
>>> Do you have suggestions that could fit well for this kind of project?
>>>
>>
>> Make the following code compile:
>>
>> ```
>> fn foo() {
>>   bar()
>>   fn bar() {}
>> }
>> ```
>>
>> i.e. allow nested function declarations after a semicolonless return
>> expression.
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] do

[Benjamin Striegel]

> If "do" is still causing confusion, I'd rather just remove it entirely.

I rather like `do`. I agree that if it's confusing it should be considered
for removal, but IMO the confusion here stems from familiarity with the
prior, obsolete semantics rather than any inherent problem with the
construct itself. I say we should wait for people to familiarize themselves
with the new closure types before thinking about giving it the axe.


On Sat, Nov 30, 2013 at 3:26 AM, Patrick Walton  wrote:

> The main reason for "do"'s existence is to make task spawning look nice.
> The closure inference was removed throughout the language because it masked
> allocation and doesn't work well with custom smart pointers. If "do" is
> still causing confusion, I'd rather just remove it entirely.
>
> Patrick
>
> Chris Morgan  wrote:
>>
>> (Do I win the prize for the shortest thread name yet?)
>>
>> error: last argument in `do` call has non-procedure type: ||
>>
>>
>> In the past three or four days I've seen at least as many enquiries in
>> #rust about this error, and I'm sure there have been at least several
>> others while I haven't been monitoring it. This is evidently causing
>>
>> quite a bit of confusion.
>>
>> Here's a summary of the change. The syntax is the same as it was before::
>>
>> do expr { block }
>> do expr |args| { block }
>> do expr(args) { block }
>> do expr(args) |args| { block }
>>
>> These used to desugar to the following, respectively::
>>
>> expr(|| { block })
>> expr(|args| { block })
>> expr(args, || { block })
>> expr(args, |args| { block })
>>
>> These now desugar to the following, respectively
>>  ::
>>
>> expr(proc() { block })
>> expr(proc(args) { block })
>> expr(args, proc() { block })
>> expr(args, proc(args) { block })
>>
>> The change is that it now accepts a procedure rather than a closure.
>> No syntax change, just a semantics change which breaks a lot of code.
>>
>> Closure: a stack function; used to be ``&fn(..) -> _``, is now ``|..|
>> -> _``. Can be called multiple times, requires no allocations and is
>> not Send.
>>
>> Procedure: a heap function; used to be ``~once fn(..) -> _``, is now
>>
>> ``proc(..) -> _``. Can be called once, requires heap allocation and is
>> Send.
>>
>> Procedures are good for sending cross-task; things like the task body
>> are a good match. Still, I think there are a few problems with how
>>
>> things are at present (i.e. after the do semantics change):
>>
>> 1. ``do`` is still using the syntax of a closure (``|..| { .. }``),
>> despite it now being a procedure.
>>
>>
>>  2. All
>> of a sudden, things using closures need to shift away from
>> using ``do`` or use procedures; this is causing confusion and may
>> cause bad design decisions where nice sugar triumphs over what is
>> actually needed; often the best solution may not be clear. (I, for
>>
>> example, had not thought about the fact that ``proc`` was going to
>> allocate; the ``~once fn`` name was clearer about that. I'll speak
>> about ``&once fn`` another time. Don't mention it now, this thread is
>>
>> just about ``do``.)
>>
>> I have two solutions that I think could answer these concerns. Leaving
>> it as it is seems a bad idea to me.
>>
>> (a) Kill ``do``
>> ---
>>
>> I've had mixed feelings about ``do``. Overall, it's pretty trivial
>>
>> syntax sugar, but it's sugar of a dubious sort, because it changes
>> something that looks like a function call with N arguments to be a
>> function call with N+1 arguments. That's just a matter of learning it.<
>>  br
>> />
>>
>> Still, ``do`` *is* nice sugar in the way it gets rid of parentheses at
>> the end. Overall, is it worth it? I don't know.
>>
>> Once ``do`` is gone, there's no problem left: just remove the sugar
>>
>> *everywhere* it was used and everything works and will do for the
>> foreseeable future.
>>
>> (b) Make ``do`` support both closures and procedures
>> --
>>
>>
>> The syntax of ``do`` can be clearly seen to include the closure
>>
>> syntax. We could easily extend it to support both closures and
>> procedures.
>>
>> Here is a proposed ``do`` using closures once more, keeping the syntax
>> it had last week::
>>
>> do expr || { block }
>> do expr(args) || { block }
>>
>> do expr |args| { block }
>> do expr(args) |args| { block }
>>
>> Here is a proposed ``do`` using procedures as the current behaviour
>> is, but with new syntax which is clearly a procedure::
>>
>> do expr proc() { block }
>> do expr(args) proc() { block }<
>>  br />do
>> expr proc(args) { block }
>>
>> do expr(args) proc(args) { block }
>>
>> This does leave these cases which are currently valid unclear::
>>
>> do expr { block }
>> do expr(args) { block }
>>
>> The options for this are (a) disallowing it; (b) making it always of
>>
>> the function types; and (c) inferring the type. I generally prefer the
>> last solution but it is the most difficult. I'm not sure how it all
>> fits into the function traits stuff at all.
>>
>> Incidentally

Re: [rust-dev] Some questions about dead-code elimination pass

[Benjamin Striegel]

> LLVM does, yes, but I'd still be interested in a perf comparison of us
> not translating the dead code compared to LLVM stripping it later.
> Clang does this, for example.

But if the idea here is also to provide a dead-code warning during
compilation, is it necessary to add this feature to the front-end or should
we presume that compilation-speed-conscious users will acknowledge the
warning and remove that code?


On Sun, Nov 24, 2013 at 8:38 AM, Corey Richardson  wrote:

> On Sat, Nov 23, 2013 at 10:44 PM, Kiet Tran  wrote:
> > 1. Is doing part (b) necessary? That is, does LLVM's optimization
> > already eliminate unused code?
> >
>
> LLVM does, yes, but I'd still be interested in a perf comparison of us
> not translating the dead code compared to LLVM stripping it later.
> Clang does this, for example.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Benjamin Striegel]

> This is an even sillier idea, but then what about keeping `loop` and
dropping `while`?

I'm not sure this is possible to disambiguate in the grammar. You'd have to
be able to tell the difference between the infinite form:

loop 

...and the conditional form:

loop  

...while keeping in mind that  can also be a .
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing some autoref magic

[Benjamin Striegel]

Obligatory link to Niko's blog post on this topic:
http://smallcultfollowing.com/babysteps/blog/2013/11/20/parameter-coercion-in-rust/

I do agree that explicitness is nice, but too much noise will harm
readability just as much as magic does.

It also doesn't help that the `&*` operator is a bit misleading: it
visually implies a deref that never actually occurs. Could lead to people
naively avoiding borrowing if they think it incurs the cost of a deref, and
just writing APIs to take owned pointers directly.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing some autoref magic

[Benjamin Striegel]

If autoref still happens on methods, does this mean that you'd be able to
get around the need to do:

sort(&mut *foo);

...by turning it into a method?

foo.sort();


On Tue, Nov 19, 2013 at 6:10 PM, Kevin Ballard  wrote:

> In general, I’m not a fan of &*, and I like auto-borrowing (autoref sounds
> like it turns T into &T, not ~T into &T). I understand the arguments to get
> rid of it though.
>
> BTW, you said that the current proposal still includes autoref for
> function invocation. That sounds to me like autoref would still apply to x
> in foo(x). Is there something else you mean by that?
>
> As I see it, the two interesting cases to consider for removing it are:
>
> 1. let x = ~Foo; foo(x); // looks like it moves x when it just borrows it
>
> 2. let mut a = ~[ … ]; sort(a); // mutates a
>
> To me, the second case seems pretty clear that it shouldn’t auto-borrow a
> ~T to a &mut T, and instead require sort(&mut *a). It’s pretty ugly, but it
> makes it clear what’s going on. This case isn’t particularly common, which
> is why losing autoref isn’t very tragic.
>
> The first case is the most common case, and it seems a shame to require
> &*x everywhere. I understand the argument that it looks like x is moved
> until you read the function signature of foo(), but I’m not convinced
> that’s important enough to uglify the code. Arguably, you already have to
> know what foo() does to understand what the code is doing.
>
> The basic argument, as I see it, is that the type signature of foo()
> shouldn’t change how the calling code treats its argument. If foo() changed
> from `fn foo(_: &T)` to `fn foo(_: ~T)` then `x` would start being moved
> instead of borrowed, which could cause errors in subsequent code in the
> caller.
>
> But the problem with this argument is that the type signature of foo()
> *already* changes how the calling code treats its argument, in a fashion
> that will surface errors in later code rather than at the call site.
> Notably, if the argument is not fully constrained to a specific type by the
> time foo(x) is called, it will further constrain the type that may not
> cause a problem until later. For example:
>
> fn foo(_: uint);
> fn bar(_: uint);
>
> let x = 1;
> foo(x);
> bar(x);
>
> This compiles just fine, but if foo() changes its argument to `int`, then
> the call to bar() will fail with a type error. More complex situations can
> be created using generic functions as well.
>
> In the case of autoref, the question is whether the value will be moved,
> rather than the type of the value, which is a slightly different issue but
> I’m not convinced it’s different enough that it needs to be specially
> addressed.
>
> The other problem with this is that, even with autoref removed, you can
> still hit the same problem of a seemingly-benign change elsewhere causing a
> compiler error in your code. Namely, if a struct has no destructor, and you
> rely on the ability to implicitly copy it (e.g. calling bar(x) where foo is
> fn bar(_: T)), then adding a destructor to the struct will cause your code
> to fail to compile, in just the same way that foo changing from `fn foo(_:
> &T)` to `fn foo(_: ~T)` will today.
>
> Overall, there just doesn’t seem to me to be a compelling reason to remove
> the ability to auto-borrow ~T into &T. Removing the ability to auto-borrow
> ~T into &mut T is more sensible though.
>
> FWIW, a lot of why I like auto-borrowing is actually due to auto-slicing
> of ~[T] into &[T] and ~str into &str. But I assume that when (if) DST
> happens, auto-slicing will just be a case of auto-borrowing. And until that
> happens I’d really like to avoiding having to say foo(v.as_slice()).
>
> -Kevin
>
> On Nov 19, 2013, at 2:08 PM, Alex Crichton  wrote:
>
> Hello rust-dev!
>
> Everyone's had their fair share of issues with autoref and autoderef,
> and it's worth considering removing certain portions of it from the
> compiler. The discussion around this has been rooted in the past, but
> has recently been brought up as part of
> https://github.com/mozilla/rust/issues/10504.
>
> The current proposal is to remove all autoref except for function
> invocations and indexing operations. The method of creating &T from ~T
> would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't
> currently benefit from the `&*foo` syntax, but they will hopefully be
> able to do such once DST lands. In the meantime coercion via type
> ascription will work and they also have `as_slice` methods.
>
> There are a few reasons backing this proposal:
>
> 1. It's inconsistent to have magical autoref in some places, but not
> in other places.
> 2. The camp of "less compiler magic is better" can fly their flag over
> this change.
> 3. Code readability does not necessarily benefit from autoref on arguments:
>
>  let a = ~Foo;
>  foo(a); // reading this code looks like it moves `a`
>  fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!
>
>  let mut a = ~[ ... ];
>  sort(a); // not only does this n

Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice

[Benjamin Striegel]

>> To what?

> `*`

...But only if you change the deref operator to something else.
Bikeshedding thread! :P


On Mon, Nov 18, 2013 at 7:27 PM, Patrick Walton wrote:

> On 11/18/13 4:23 PM, Ziad Hatahet wrote:
>
>> ...and possibly change `~`.
>>>
>>
>> To what?
>>
>
> `*`
>
>
> Patrick
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust docs

[Benjamin Striegel]

And by replace I mean we could relegate the current tutorial to an
"advanced" tutorial or somesuch.


On Thu, Nov 14, 2013 at 12:30 PM, Benjamin Striegel
wrote:

> I would welcome such an effort, and suggest that it live as its own
> project, outside of the Rust repo. We really aren't set up currently to
> handle rapid and frequent documentation changes. Once it gets to a
> reasonable level of maturity we could then give it a mention from the main
> tutorial, and then once it's ready we could replace the current tutorial
> entirely.
>
>
> On Thu, Nov 14, 2013 at 11:58 AM, Gaetan  wrote:
>
>> I would love helping on this matter, I'm use to setting up automatic
>> documentation generation (rst, sphinx, doxygen,...).
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/14 Philip Herron 
>>
>>> I would defineltly like to see a clone of the python tutorial because it
>>> really does it so well going inch by inch building up what way things work
>>> i am not a web developer but would love to write content i wonder is it
>>> possible to start a github project for this using sphinx i think it uses
>>> isn't it?
>>>
>>>
>>> On 14 November 2013 15:38, Corey Richardson  wrote:
>>>
>>>> On Thu, Nov 14, 2013 at 10:03 AM, Daniel Glazman
>>>>  wrote:
>>>> > The Tutorial is the entry point for all people willing to investigate
>>>> > Rust and/or contribute to Servo. I think that document is super
>>>> > precious, super-important. Unfortunately, I don't think it is really a
>>>> > tutorial but only a lighter manual. Examples are here even more
>>>> > important than in the case of the Manual above. A good Tutorial is
>>>> > often built around one single programming task that becomes more and
>>>> > more complex as more features of the language are read and
>>>> > known. Furthermore, the Tutorial has clearly adopted the language
>>>> > complexity of the reference manual, something that I think should be
>>>> > in general avoided. I also think all examples should be buildable
>>>> > and produce a readable result on the console even if that result is a
>>>> > build or execution error. That would drastically help the reader.
>>>> >
>>>> > All in all, I think the Tutorial needs some love and probably a
>>>> > technical writer who is not working on the guts of Rust, someone who
>>>> > could vulgarize the notions of the Manual into an easy-to-read,
>>>> > simple-to-experiment, step-by-step tutorial and avoiding in general
>>>> > vocabulary inherited from programming language science.
>>>> >
>>>>
>>>> I agree, partially. I think "Rust for Rubyists" fills this role quite
>>>> well for now. Generally I  think the language tutorial should not try
>>>> to hide complexity or paper over things, at the very least so it can
>>>> be complete and correct. I think the Python tutorial is a good
>>>> benchmark. We might even be able to rip off the Python tutorial's
>>>> structure wholesale.
>>>>
>>>> The "on-boarding" process is still very rough. Maybe some sort of
>>>> live-comment system would work well for finding pain points, where one
>>>> can add comments/feedback while reading the tutorial.
>>>> ___
>>>> Rust-dev mailing list
>>>> Rust-dev@mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
>>>
>>>
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust docs

[Benjamin Striegel]

I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo. We really aren't set up currently to
handle rapid and frequent documentation changes. Once it gets to a
reasonable level of maturity we could then give it a mention from the main
tutorial, and then once it's ready we could replace the current tutorial
entirely.


On Thu, Nov 14, 2013 at 11:58 AM, Gaetan  wrote:

> I would love helping on this matter, I'm use to setting up automatic
> documentation generation (rst, sphinx, doxygen,...).
>
> -
> Gaetan
>
>
>
> 2013/11/14 Philip Herron 
>
>> I would defineltly like to see a clone of the python tutorial because it
>> really does it so well going inch by inch building up what way things work
>> i am not a web developer but would love to write content i wonder is it
>> possible to start a github project for this using sphinx i think it uses
>> isn't it?
>>
>>
>> On 14 November 2013 15:38, Corey Richardson  wrote:
>>
>>> On Thu, Nov 14, 2013 at 10:03 AM, Daniel Glazman
>>>  wrote:
>>> > The Tutorial is the entry point for all people willing to investigate
>>> > Rust and/or contribute to Servo. I think that document is super
>>> > precious, super-important. Unfortunately, I don't think it is really a
>>> > tutorial but only a lighter manual. Examples are here even more
>>> > important than in the case of the Manual above. A good Tutorial is
>>> > often built around one single programming task that becomes more and
>>> > more complex as more features of the language are read and
>>> > known. Furthermore, the Tutorial has clearly adopted the language
>>> > complexity of the reference manual, something that I think should be
>>> > in general avoided. I also think all examples should be buildable
>>> > and produce a readable result on the console even if that result is a
>>> > build or execution error. That would drastically help the reader.
>>> >
>>> > All in all, I think the Tutorial needs some love and probably a
>>> > technical writer who is not working on the guts of Rust, someone who
>>> > could vulgarize the notions of the Manual into an easy-to-read,
>>> > simple-to-experiment, step-by-step tutorial and avoiding in general
>>> > vocabulary inherited from programming language science.
>>> >
>>>
>>> I agree, partially. I think "Rust for Rubyists" fills this role quite
>>> well for now. Generally I  think the language tutorial should not try
>>> to hide complexity or paper over things, at the very least so it can
>>> be complete and correct. I think the Python tutorial is a good
>>> benchmark. We might even be able to rip off the Python tutorial's
>>> structure wholesale.
>>>
>>> The "on-boarding" process is still very rough. Maybe some sort of
>>> live-comment system would work well for finding pain points, where one
>>> can add comments/feedback while reading the tutorial.
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] typing in rust

[Benjamin Striegel]

> but why is it valid inside the same scope as illustrated in the code
example?

One use is to allow you to alter the mutability of variables as needed
(often referred to as "freezing" and "thawing"):

let x = 2;  // this is immutable
...  // do stuff that requires x to be immutable
let mut x = x;  // make x mutable
... // do stuff that requires x to be mutable
let x = x;  // make x immutable again

And yes, the fact that that last line isn't a no-op is definitely something
to watch out for. :)


On Wed, Nov 13, 2013 at 11:25 AM, Joshua Rodgers  wrote:

> I'm curious as to why this is valid, though?  This makes sense if you're
> inside a new or nested scope, but why is it valid inside the same scope as
> illustrated in the code example?
>
> I can understand it from the perspective that I need to mask a function
> name (but that's a nested scope to me, at that point).
>
>
> On Wed, Nov 13, 2013 at 8:54 AM, Scott Lawrence  wrote:
>
>> I would think that `test()` (the function) is in scope for the duration
>> of `let test =`, and then the new definition masks the old one. Similarly,
>>
>> let x = 2;
>> let x = x + 2;
>>
>> If you change the last line to /call/ test(), you should get an error.
>>
>>
>> On Wed, 13 Nov 2013, Philip Herron wrote:
>>
>>  Hey all
>>>
>>> I am still learning but i just tried something which i expected to give
>>> an
>>> error but works:
>>>
>>> fn test () -> int {
>>>  1
>>> }
>>>
>>> fn main () {
>>>  let test = test ();
>>>  println (format! ("{}", test));
>>> }
>>>
>>> I guess on compilation the names are mangled against their types or
>>> something so you can differentiate between test the function and test the
>>> variable. Not sure would be nice to get some clarification what this
>>> behavior is.
>>>
>>> Thanks
>>>
>>> --Phil
>>>
>>>
>> --
>> Scott Lawrence
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] About owned pointer

[Benjamin Striegel]

> Except I cannot find them.

The dynamically-sized type posts are sort of scattered all over Niko's
blog. You can start here:

http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/

for a general overview.


On Fri, Nov 8, 2013 at 1:38 PM, spir  wrote:

> On 11/08/2013 07:20 PM, Patrick Walton wrote:
>
>> Because then `str` would not be a dynamically sized type.
>>
>
> (I'm not convinced --yet-- strings *must* have dynamic size at all, as I
> never need this feature even if I do quite a lot of text processing. When
> generating runtime produced strings, I'd rather concat all bits at once at
> the very end, thus knowing the final size. No support for this is needed:
> one never writes into a growable string buffer, instead always concat all
> at once. But this may be another, distinct story. And there may be use
> cases I'm unaware of, even common ones.)
>
>
>  Please read the blog posts on dynamically sized types.
>>
>
> All right, I'll do.
> PS: Except I cannot find them.
> Don't seem listed in the list of blog post at https://github.com/mozilla/
> rust/wiki/Docs
> Also not in the archives of your own blog at: http://pcwalton.github.io/
> blog/archives/
>
> Denis
>
>  spir  wrote:
>>
>>> On 11/08/2013 09:53 AM, Daniel Micay wrote:
>>>
 It couldn't be called `str`, because `&str` is a slice.

>>>
>>> Why couldn't str be slices? (eg somewhat like arrays are slices in D)
>>> Also, i don't understand literals in Rust currently. Same for static
>>> arrays.
>>>
>>> Denis
>>> ___
>>>
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>>  ___
>
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] About owned pointer

[Benjamin Striegel]

> I would like to take steps to move to that world post Rust 1.0.

I'd be interested to read more about this, and the reasons why it must be
deferred until after 1.0. Is it just "too much work to do right now", or
does it require some broader ambitious feature (HKT, etc)?


On Fri, Nov 8, 2013 at 12:35 PM, Patrick Walton wrote:

> On 11/8/13 9:26 AM, spir wrote:
>
>> What are the present implementations of strings and arrays in Rust? And
>> what about fixed size (esp for strings)?
>>
>
> struct RustString {
> int size;
> int cap;
> char ptr[]
> };
>
> typedef *RustString ~str;
>
> (If `~` were a valid identifier character in C, that is.) ;)
>
> But Daniel did some performance measurements and found that this had
> suboptimal performance characteristics when compared to:
>
> struct ~str {
> char *ptr;
> int size;
> int cap;
> }
>
> So we're changing to the latter.
>
> By the way, I agree with Daniel that in an ideal world none of this would
> be baked into the compiler (except syntactically), and I would like to take
> steps to move to that world post Rust 1.0. However, given that we have
> dynamically sized types and as a result we have to define `~str` to mean
> *something*, we have to build in some representation into the compiler.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] GZip and Deflate

[Benjamin Striegel]

I can't answer your questions, but I do want to say that this is very
interesting!

> Rust compression is about 1.8 times slower, decompression is about 3
times slower than gzip.

Have you tried profiling this to see where our bottlenecks are? It would be
great if we could use this as an opportunity to improve our performance.


On Fri, Nov 1, 2013 at 6:02 AM, William Wong  wrote:

> I wanted to add full compression support to Rust.  Full support means
> stream compression (good for http compression) and multiple call
> compression (compressing large file with multiple batches of read).  To get
> to that point, the miniz.cpp and deflate API in Rust runtime need to be
> enhanced to overcome a few limitations.
>
> I've worked with the author of miniz.c (Rich Geldreich) to merge changes
> into miniz.c on his codeline for the needed API for Rust, and resolved the
> decompression bug in miniz's code when working with gzip'ed file.
>
> http://code.google.com/p/miniz/issues/detail?id=25&can=1
> http://code.google.com/p/miniz/issues/detail?id=23&can=1
>
> I've implemented a full set of deflate API in Rust to support stream
> compression and multiple call compression, with caller-driven and
> callee-driven pipe style API.  Also I've written the Rust GZip library with
> stream support like GZipReader and GZipWriter.  For testing, I've
> re-implemented most of the gzip command line program on top of the Rust
> GZip library.  Some performance data for the interested: Rust compression
> is about 1.8 times slower, decompression is about 3 times slower than
> gzip.  Overall it seems solid.  See
> https://github.com/williamw520/rustyzip for the source.
>
> Now I need help to merge the changes into the Rust master codeline.  There
> are couple things.
>
> 1. What license to assign for the new files?  I use MPL currently.
> 2. There's a new version of miniz.cpp needed for things to work.  Is the
> Rust runtime still open for C++ file changes?
> 3. There are two new files for the deflate library (deflate.rs) and the
> gzip library (gzip.rs).  Which Rust runtime library is the appropriate
> one to put them in?
> 4. Should the command line tool rgzip stay in an outside codeline or be
> merged into the Rust runtime?  If merging in, where is a good place for
> tools?
>
> Thanks
>
> William
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust and Servo presentations, demos

[Benjamin Striegel]

Before you give the presentation, would you mind showing it to us here? I
for one would be happy to review your code and make sure it's up to date.


On Thu, Oct 31, 2013 at 5:04 AM, KAMI911 KAMI911  wrote:

> Hi Folks, (sorry for cross posting),
>
> I am a Hungarian contributor to Mozilla. Next weekend I will have a
> presentation about Mozilla Labs projects and I would like to introduce Rust
> and Servo. Can you point some presentations, demos that available for
> everyone?
>
> Thank you in advance!
>
> Üdvözlettel / Best Regards:
>
> Kálmán (KAMI) Szalai
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On Stack Safety

[Benjamin Striegel]

> you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on
64 bit).

Actually, goroutines have a default stack size of 8kb since 1.2.

Also, applicable to this discussion, in 1.3 Go will be moving away from
segmented stacks to contiguous growable stacks:
https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub


On Tue, Oct 22, 2013 at 12:52 AM, Patrick Walton wrote:

> On 10/21/13 8:48 PM, Daniel Micay wrote:
>
>> Segmented stacks result in extra code being added to every function,
>> loss of memory locality, high overhead for calls into C and
>> unpredictable performance hits due to segment thrashing.
>>
>> They do seem important for making the paradigm of one task per
>> connection viable for servers, but it's hard to balance that with other
>> needs.
>>
>
> I'm not sure they're that important even for that use case. Is 4 kB (page
> size) per connection that bad? You won't compete with nginx's memory usage
> (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB
> stacks), but you do compete with Go (4 kB initial stack segment) and Erlang
> (2.4 kB on 64 bit).
>
> Besides, if we really wanted to go head-to-head with nginx we could
> introduce "microthreads" with very small stack limits (256 bytes or
> whatever) that just fail if you run off the end. Such a routine would be
> utterly miserable to program correctly but would be necessary if you want
> to compete with nginx in the task model anyhow :)
>
> Realistically, though, if you are writing an nginx killer you will want to
> use async I/O and avoid the task model, as even the overhead of context
> switching via userspace register save-and-restore is going to put you at a
> disadvantage. Given what I've seen of the nginx code you aren't going to
> beat it without counting every cycle.
>
> Patrick
>
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev