On 13-07-28 09:24 PM, Alex Crichton wrote:
I would love comments/suggestions on this system. I think that this takes into
account almost all of the feedback which I've received about how formatting
strings should work, but extra sets of eyes are always useful!
In general I'm really happy
I mentioned checksum algorithms because I have a motivation to work on them
and thought Rust could have the most popular ones in stdlib. I wasn't
suggesting to put them into the same category as digests.
For the record, I'm looking at Go's crypto[1] and hash[2] packages as an
indicator of what
Hi,
On 29/07/2013 06:24, Alex Crichton wrote:
Having thought a bit more concretely about this, using the suggestions here,
and talking to Graydon on IRC I've come up with the following design for a
string formatting library. I think that this addresses the comments in the
responses to my
On 2013-07-29, at 11:04 , Huon Wilson wrote:
On 29/07/13 18:26, Masklinn wrote:
I don't have much to say, but
On 2013-07-29, at 06:24 , Alex Crichton wrote:
* Any argument can be selected (0-indexed from the start)
keyword/named selection is *really* great for longer/more busy patterns,
On 29/07/2013 6:36 AM, Graydon Hoare gray...@mozilla.com wrote:
On 13-07-28 04:06 PM, Steven Ashley wrote:
{0:(
if count == 0 then (You have no messages.)
else (You have {count:#} messages.)
)}
That's exactly the case that the nested pluralization forms are for. Read
the docs
On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson bander...@mozilla.com wrote:
FWIW I prefer the terms box and reference. I don't really understand the
idea that only * is 'semantically a pointer' though.
Unique boxes
Hello and welcome to the eighth issue of *This Week in Rust*. Due to me being
busy and forgetful over the weekend, this is a special issue, *Last Week in
Rust*.
!-- more --
# What's cooking on `master`?
Issue churn continues to be negative, -15 this week. A total of 63 PRs were
merged.
##
This would make for some interesting/confusing calling conventions. It
would also mean T and mut T would no longer share a representation; int
would simply be int, but mut int would still have to be a pointer.
Borrowing mut T to T would be a dereference if T is pointer size or
smaller? The only
REGARDING:
- Graydon wants to investigate using the Memory Pool System as the Rust GC,
rather than a bespoke one. The
[MPS](http://www.ravenbrook.com/project/mps/) is
a very mature and robust memory management library.
Reading through and seeing one of the MPS creators initial design goals :
I wrote an implementation of text encoding/decoding for ISO*-Unicode
in Rust, available here: https://github.com/haard/rust-codecs
I use approximately the same technique as the cpython implementation,
and it works by parsing unicode.org specifications and generating Rust
source; a charmap for
Wow, it *is* indeed a coincidence: I'm also working on the character
encoding library.
https://github.com/lifthrasiir/rust-encoding
Although this one is much more sophiscated that it supports an API for
error detection and recovery. I'm not sure the whole library merits
the inclusion however, as
Le 29/07/2013 18:58, Fredrik Håård a écrit :
I wrote an implementation of text encoding/decoding for ISO*-Unicode
in Rust, available here:https://github.com/haard/rust-codecs
I use approximately the same technique as the cpython implementation,
and it works by parsing unicode.org specifications
On Mon, Jul 29, 2013 at 1:21 PM, Thiez thi...@gmail.com wrote:
This would make for some interesting/confusing calling conventions. It would
also mean T and mut T would no longer share a representation; int would
simply be int, but mut int would still have to be a pointer. Borrowing mut
T to T
On Mon, Jul 29, 2013 at 7:21 PM, Thiez thi...@gmail.com wrote:
This would make for some interesting/confusing calling conventions. It would
also mean T and mut T would no longer share a representation; int would
simply be int, but mut int would still have to be a pointer.
Yes.
Borrowing mut
Hi,
I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn name(var: type, ...) - return_type {...}
instead
On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
Hi,
I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn
That modification could be subtle, yet powerful. It would make the language
more consistent, at the very least.
Sincerely,
Josh
On Jul 29, 2013 7:29 PM, Patrick Walton pwal...@mozilla.com wrote:
On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
Hi,
I'm observing rust development for some time,
I don't agree that the type of a function and the return type of a function
are the same thing (specifically, the type of the function contains the
return type). :) If nothing else, this would make the function signatures
of higher-order functions much harder to read IMO.
On Mon, Jul 29, 2013 at
Come to think of it, it might also make the grammar for function signatures
ambiguous, given that we allow null return types to be omitted.
On Mon, Jul 29, 2013 at 9:18 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
I don't agree that the type of a function and the return type of a
This would make function signatures harder to read in some instances,
particularly when using closures and higher-order functions:
let f: fn(T): T = …;
fn hofT(x: T, f: fn(T): T): fn(T): T { … }
Compare to the current syntax:
let f: fn(T) - T = …;
fn hofT(x: T, f: fn(T) - T)
Neither is perfect. There is definitely room for improvement in both
options.
On Jul 29, 2013 9:08 PM, Brendan Zabarauskas bjz...@yahoo.com.au wrote:
This would make function signatures harder to read in some instances,
particularly when using closures and higher-order functions:
let f:
Thanks for all the comments everyone! I'll see if I can address a good
number of them here:
- I don't see how the example {:date} is generated from the grammar.
Though I do think custom (especially culture-specific) formatter
functions do need some support. Money and dates are the big two.
I'm personally not very familiar with the Sleepycat license (as MPS seems
to use: https://github.com/Ravenbrook/mps-temporary).
Would proprietary code have to be shipped in separate binaries than the
Rust runtime, or would commercial licensing be required?
Kevin
--
Kevin Cantu
On Mon, Jul
If the licensing terms aren't suitable for you (for example, you're
developing a closed-source commercial product or a *compiler run-time*
*system*) you can easily license the MPS under different terms from
Ravenbrook. Please write to us at `*mps-questi...@ravenbrook.com*`_
for more information.
I didn't raise the subject since it seems late for a huge syntax change
but if I had to change something about the function syntax I would
change it to:
fn function (var: type, ... - returnType) {...}
I really think it would be more readable especially in the case of
Brendan Zabarauskas
This would make deeply-nested HOF easier to read, but I'm not a fan of the
way that `fn foo(-int) {` looks for functions with no arguments.
Because I forgot to register my opinion previously, I do like the way that
the current syntax reads in the common case, including the use of the
26 matches
Mail list logo
