The Development of the Rust language from Mozilla and Graydon Hoare is going on. It will probably become a quite interesting system language, quite more interesting than Go. One of the most interesting features of Rust will be its typestate.

Rust has structural typing too, this is sometimes useful (but to use it well you need something like pattern matching used in functional languages like ML, that I don't know if is present in Rust).


Graydon is following D idea of putting a basic unit testing feature in the language:
https://mail.mozilla.org/pipermail/rust-dev/2010-December/000160.html
https://mail.mozilla.org/pipermail/rust-dev/2010-December/000163.html
https://mail.mozilla.org/pipermail/rust-dev/2010-December/000165.html
Rust also puts basic logging as a built-in feature.


This is a blog post about Rust type inference: http://pcwalton.blogspot.com/2010/10/rust-features-i-type-inference.html

Rust doesn't have a whole program type inferencer (as ML), like a Hindley-Milner algorithm, to keep things simple and allow separate compilation (and probably to keep compilation times low, etc). So you have to give type to function arguments, and if you want you are free to use "auto" everywhere inside the function to infer types locally. I think this is good. So on this it's quite similar to D, but there are some differences.

Rust allows to do this ("log" is a built-in logging feature, I don't know how they call the logarithm function):


auto x;
if (localtime().hours >= 8) {
    x = "awake!"
} else {
    x = "asleep, go away."
}
log "I'm " + x;


From the blog post:

>Rust features what I call feed-forward type inference, which is summed up by this rule: Variables have no type until they are assigned a value, at which point their type can't change.<

>Here, we didn't initialize x in its declaration, but this code still compiles and runs properly. This is because Rust is able to wait until x is assigned to determine its type. Unlike, say, C# (and, of course, languages like ML in which variables must be assigned a value at declaration time), Rust doesn't require that auto declarations be initially assigned a value to determine a type for them. At the same time, unlike C, the compiler will emit an error if you ever forget to assign a value to the variable in any branch of your code. For instance, if you omit the else branch above, the code won't compile.<


Rust is statically typed, so this is an error, it's not possible (unless you use some kind of variant):

log "do you want to add strings or ints?";
auto use_str = input.readline == "strings";
if (use_str) {
    a = "hello ";
    b = "world!";
} else {
    a = 1;
    b = 1;
}
log a + b;


Both branches of the "if" must assign the same types to a and b, like when in D you use an auto return type, and the D compiler makes sure all your return statements return exactly the same type.


"Variables have no type until they are assigned a value, at which point their type can't change." looks meaningless if you see types as timeless things, that are are always true and immutable for a variable. But in Rust there are typestates, so while a variable can't change type, its type sometimes changes state along the flow of the code, such state of the type may be different in different parts of the code.

Bye,
bearophile

> Rust is statically typed, so this is an error, it's not possible (unless you use some kind of variant):

Not quite clear in the example but just add an extra line after if block.

> log "do you want to add strings or ints?";
> auto use_str = input.readline == "strings";
> if (use_str) {
>     a = "hello ";
>     b = "world!";
> } else {
>     a = 1;
>     b = 1;
> }
> auto c = b - a; // wah?
>
> log a + b;
>
> ...
>
> Bye,
> bearophile

Already love it, lowercase ftw!
Although built-in logging is nice, both the name and the operator of logging are very bad choices.
Especially for a standard library.

> both the name and the operator of logging are very bad choices.

Oh '+' is string concat in Rust, and log is not that bad either!

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:iivb5n$na3$1@digitalmars.com...
>
> auto x;
> if (localtime().hours >= 8) {
>    x = "awake!"
> } else {
>    x = "asleep, go away."
> }
> log "I'm " + x;
>

That would be really nice to have in D. There's been many times I've needed to move a declaration up one scope from its initialization and was therefore forced to get rid of the "auto". Not a major problem obviously, but that sure would be nice.

On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
> "bearophile"<bearophileHUGS@lycos.com>  wrote in message
> news:iivb5n$na3$1@digitalmars.com...
>>
>> auto x;
>> if (localtime().hours>= 8) {
>>     x = "awake!"
>> } else {
>>     x = "asleep, go away."
>> }
>> log "I'm " + x;
>>
>
> That would be really nice to have in D. There's been many times I've needed
> to move a declaration up one scope from its initialization and was therefore
> forced to get rid of the "auto". Not a major problem obviously, but that
> sure would be nice.

I don't like that at all. The second main feature of staticity if self-doc code. How is one, as a reader, supposed to guess what x is and means?
I'm not a great fan of auto, neither, use it would happily live w/o it, except for functions operating on ranges, that return types coming from who-knows where (certainly another planet).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir Wrote:

> On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
> > "bearophile"<bearophileHUGS@lycos.com>  wrote in message news:iivb5n$na3$1@digitalmars.com...
> >>
> >> auto x;
> >> if (localtime().hours>= 8) {
> >>     x = "awake!"
> >> } else {
> >>     x = "asleep, go away."
> >> }
> >> log "I'm " + x;
> >>
> >
> > That would be really nice to have in D. There's been many times I've needed to move a declaration up one scope from its initialization and was therefore forced to get rid of the "auto". Not a major problem obviously, but that sure would be nice.
> 
> I don't like that at all. The second main feature of staticity if self-doc
> code. How is one, as a reader, supposed to guess what x is and means?
> I'm not a great fan of auto, neither, use it would happily live w/o it, except
> for functions operating on ranges, that return types coming from who-knows
> where (certainly another planet).

How about this?
spir Wrote:

auto x =
  if (localtime().hours>= 8) {
    "awake!"
  } else {
    "asleep, go away."
  };

log "I'm " + x;

I think it solves the problem of unkown type for x nicely. And it's very close to what we already have. something ? foo : bar might do the same, but if() [} else {} is much more readable IMO.

Jean Crystof Wrote:

> How about this?
> spir Wrote:
> 
> auto x =
>   if (localtime().hours>= 8) {
>     "awake!"
>   } else {
>     "asleep, go away."
>   };
> 
> log "I'm " + x;
> 
> I think it solves the problem of unkown type for x nicely. And it's very close to what we already have. something ? foo : bar might do the same, but if() [} else {} is much more readable IMO.

Humm, what we currently have:

auto x = {
       if (localtime().hours>= 8) {
          "awake!"
       } else {
          "asleep, go away."
        };
   }();

log "I'm " + x;

On 2/10/11, spir <denis.spir@gmail.com> wrote:
> I'm not a great fan of auto, neither, use it would happily live w/o it,
> except
> for functions operating on ranges, that return types coming from who-knows
> where (certainly another planet).

auto is great for rapid prototyping. And so are templated functions. After I'm satisfied with the functionality of my code I usually replace much of my use of auto with the actual type (mostly variable declarations). auto is still useful in templates, where writing a return type can be complicated.

Nick Sabalausky wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:iivb5n$na3$1@digitalmars.com...
>> auto x;
>> if (localtime().hours >= 8) {
>>    x = "awake!"
>> } else {
>>    x = "asleep, go away."
>> }
>> log "I'm " + x;
>>
> 
> That would be really nice to have in D.


auto x = (localtime().hours >= 8) ? "awake!" : "asleep, go away.";

On 2/10/11, Walter Bright <newshound2@digitalmars.com> wrote:
> auto x = (localtime().hours >= 8) ? "awake!" : "asleep, go away.";

Aye, a one liner!

I hate seeing things like this:
if (funcall())
{
    var = "foo";
}
else
{
    var = "bar";
}

So much clutter instead of using the simple:
var = funcall() ? "foo" : "bar";

I also see this sometimes:

auto var = funcall();
if (var == "foo" || var == "bar" || var == "foobar" || var == "barfoo")
{
    // some complex code
}
else if (var == "blue" || var == "green")
{
    // some complex code
}
else if ()// more and more code..
{ }

But not many people seem to know that D supports strings in case statements:
switch(funcall())
{
    case "foo":
    case "bar":
    case "foobar":
    case "barfoo":
    {
        // complex code
    }
    break;
    case "blue":
    case "green":
    {
       // complex code
    }
    break;
    default:
}

Not everybody will like this since it wastes a lot of vertical space. But at least it fits in 80 columns! (:p). Plus you don't need to create a temporary variable.

The cool thing is the compiler will warn you if you miss out setting the default switch, which is something you won't get with if/elseif's.

The final switch statement is even better when using enums. Added another enum member, but forgot to update the final switch statement? Boom, compiler error!

It's a great thing for avoiding bugs imo.