User: Password:
|
|
Subscribe / Log in / New account

Rust-lang

Rust-lang

Posted Apr 5, 2013 8:21 UTC (Fri) by dgm (subscriber, #49227)
In reply to: Rust-lang by man_ls
Parent article: Mozilla and Samsung building a new browser engine

I don't find those much problematic, but go read the tutorial, and in section 3.1 you will find that:

let var = 
  if (condition1) {
    value1
  } else {
    value2
  };
is completely different from:
let var = 
  if (condition1) {
    value1;
  } else {
    value2;
  }

The second one would be almost surely a mistake, but the compiler would not complain. In my opinion this defeats the purpose of doing Yet Another Curly Brace Language. The mere fact that they feel they need to point it out in the tutorial is a clear sign that something is wrong here.

I hope they get this sorted out before 1.0


(Log in to post comments)

Rust-lang

Posted Apr 5, 2013 12:39 UTC (Fri) by renox (subscriber, #23785) [Link]

Yes, in Rust you have to be very cautious about the usage of ';'!
Thankfully as the return type of functions is not inferred but given explicitly in many cases the compiler will be able to complain, not in the example you've given though.

Apparently they don't like 'return', I'm not sure why.. Maybe it's because it's 'big' (they seem to like short keyword)?
In this case, they could have done like SmallTalk use '^' instead of return.

Another weird part is the for: 'for v.each |e| { bar(*e);}', uh?
The languages I know use either for (for e in set { .. }' or each (set.each |e| { .. }) but having both for AND each at the same time??

Also code with named lifetime seems really hard, but I don't think that's a syntax issue, it's just a difficult concept to master.

Rust-lang

Posted Apr 5, 2013 12:54 UTC (Fri) by HelloWorld (guest, #56129) [Link]

It is trivial to add a warning for that. Just check if a local variable is bound to a value of type ().

Rust-lang

Posted Apr 5, 2013 17:01 UTC (Fri) by jimparis (subscriber, #38647) [Link]

A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.

Rust-lang

Posted Apr 5, 2013 22:18 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.
It doesn't matter whether the branch can be taken, the values of both branches are of type (), and it doesn't make sense to store a value of that type in a variable.

Rust-lang

Posted Apr 5, 2013 22:47 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> It doesn't matter whether the branch can be taken, the values of both branches are of type ()

So imagine a case where both branches are different. Or where the conditional is deep inside a function before the return value finally gets to the assignment. If having a conditional return type () makes sense in some cases and not others, then you can't trivially warn about it.

Rust-lang

Posted Apr 6, 2013 0:26 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> So imagine a case where both branches are different.
That's a type error in itself in most cases. In order for such code to typecheck, the branches' types must have a common supertype. As far as I can see, Rust allows only interfaces to form hierarchies, and I don't know if it's even possible for () to implement interfaces. But even if it is, this situation is going to be so rare that it's not worth losing any sleep over it.

Rust-lang

Posted Jun 21, 2013 8:04 UTC (Fri) by jessopher (guest, #91536) [Link]

You can return a pointer to a value of a type that satisfies a trait constraint, but not a direct value.

Imagine something like this

fn foo(which: bool) -> Number
{
if which { return (1 as int); }
else { return (1 as byte); }
}

now ask yourself "what is the bit-width of the value returned?", and "how is the implementation of the interface specific to each subtype determined at runtime?". For pointers, what is actually pointed to can be something that carries runtime type information, like the bit-width of the value, and the address of some dispatch table.

So really the situation isn't a rarity, it is non-existent. You are not going to accidentally return a pointer to (), from a function that has a polymorphic return type that () satisfies.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds