Re: More on Rust
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.
Re: More on Rust
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!
Re: More on Rust
"bearophile" 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.
Re: More on Rust
On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
"bearophile" 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
Re: More on Rust
spir Wrote:
> On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
> > "bearophile" 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.
Re: More on Rust
On 2/10/11, spir 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.
Re: More on Rust
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;
Re: More on Rust
Nick Sabalausky wrote:
"bearophile" 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.";
Re: More on Rust
On 2/10/11, Walter Bright 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.
Re: More on Rust
On 2011-02-10 20:15, Walter Bright wrote:
Nick Sabalausky wrote:
"bearophile" 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.";
For this simple if statement it works but as soon you have a few lines
in the if statement it will become really ugly. But one could wrap the
if statement in a function instead. In other languages where statements
really are expressions this works:
auto x = if (localtime().hours >= 8)
"awake!";
else
"asleep, go away.";
log "I'm " + x;
--
/Jacob Carlborg
Re: More on Rust
Jacob Carlborg Wrote:
> On 2011-02-10 20:15, Walter Bright wrote:
> > Nick Sabalausky wrote:
> >> "bearophile" 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.";
>
> For this simple if statement it works but as soon you have a few lines
> in the if statement it will become really ugly. But one could wrap the
> if statement in a function instead. In other languages where statements
> really are expressions this works:
>
> auto x = if (localtime().hours >= 8)
> "awake!";
> else
> "asleep, go away.";
>
> log "I'm " + x;
Other languages may have bloated syntaxes, with no particular benefit.
auto x = localtime().hours >= 8 ?
"awake!"
:
"asleep, go away.";
log( "I'm " ~ x );
If the expressions are complex I put them in functions.
1) It hides and isolates details, which allows you to focus on the more
abstract aspects.
2) It gives the expression a name and facilitates reuse.
Re: More on Rust
On 2011-02-11 08:39, Jim wrote:
Jacob Carlborg Wrote:
On 2011-02-10 20:15, Walter Bright wrote:
Nick Sabalausky wrote:
"bearophile" 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.";
For this simple if statement it works but as soon you have a few lines
in the if statement it will become really ugly. But one could wrap the
if statement in a function instead. In other languages where statements
really are expressions this works:
auto x = if (localtime().hours>= 8)
"awake!";
else
"asleep, go away.";
log "I'm " + x;
Other languages may have bloated syntaxes, with no particular benefit.
auto x = localtime().hours>= 8 ?
"awake!"
:
"asleep, go away.";
log( "I'm " ~ x );
If the expressions are complex I put them in functions.
1) It hides and isolates details, which allows you to focus on the more
abstract aspects.
2) It gives the expression a name and facilitates reuse.
And that was the first thing I said one could do.
--
/Jacob Carlborg
Re: More on Rust
Jim Wrote:
> Jacob Carlborg Wrote:
>
> > On 2011-02-10 20:15, Walter Bright wrote:
> > > Nick Sabalausky wrote:
> > >> "bearophile" 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.";
> >
> > For this simple if statement it works but as soon you have a few lines
> > in the if statement it will become really ugly. But one could wrap the
> > if statement in a function instead. In other languages where statements
> > really are expressions this works:
> >
> > auto x = if (localtime().hours >= 8)
> > "awake!";
> > else
> > "asleep, go away.";
> >
> > log "I'm " + x;
>
>
>
> Other languages may have bloated syntaxes, with no particular benefit.
>
>
> auto x = localtime().hours >= 8 ?
> "awake!"
> :
> "asleep, go away.";
>
> log( "I'm " ~ x );
You're right. ? : is a masterpiece among syntaxes. Maybe a bit too terse, but
it does exactly what people expect it to do and it has existed since C was
born.
Re: More on Rust
On 02/11/2011 08:39 AM, Jim wrote:
Jacob Carlborg Wrote:
On 2011-02-10 20:15, Walter Bright wrote:
Nick Sabalausky wrote:
"bearophile" 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.";
For this simple if statement it works but as soon you have a few lines
in the if statement it will become really ugly. But one could wrap the
if statement in a function instead. In other languages where statements
really are expressions this works:
auto x = if (localtime().hours>= 8)
"awake!";
else
"asleep, go away.";
log "I'm " + x;
Other languages may have bloated syntaxes, with no particular benefit.
auto x = localtime().hours>= 8 ?
"awake!"
:
"asleep, go away.";
log( "I'm " ~ x );
If the expressions are complex I put them in functions.
1) It hides and isolates details, which allows you to focus on the more
abstract aspects.
2) It gives the expression a name and facilitates reuse.
Agreed.
But in practice I often end up beeing dubious about seemingly nice features
like, precisely, the ternary operator. In languages that do not have such a
nicety people end up writng eg:
if (localtime().hours>= 8) x = awake;
else x = "asleep, go away.";
Apart from the very mild annoyance, I guess, of writing twice "x =", this is
all gain: code is both more compact and legible.
Precisely, because the ternary operator is a bit weird syntactically (and not
that commonly needed and used in real code), people feel, just like you, the
need to clarify it in code, finally using more vertical space. Note that the
case here is the simplest possible, expressions being plain literal constants.
I personly only consume 3 lines:
auto x = (localtime().hours>= 8)
? "awake!"
: "asleep, go away.";
What do you think?
Denis
--
_
vita es estrany
spir.wikidot.com
Re: More on Rust
spir Wrote:
> On 02/11/2011 08:39 AM, Jim wrote:
> > Jacob Carlborg Wrote:
> >
> >> On 2011-02-10 20:15, Walter Bright wrote:
> >>> Nick Sabalausky wrote:
> "bearophile" 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.";
> >>
> >> For this simple if statement it works but as soon you have a few lines
> >> in the if statement it will become really ugly. But one could wrap the
> >> if statement in a function instead. In other languages where statements
> >> really are expressions this works:
> >>
> >> auto x = if (localtime().hours>= 8)
> >> "awake!";
> >>else
> >> "asleep, go away.";
> >>
> >> log "I'm " + x;
> >
> >
> >
> > Other languages may have bloated syntaxes, with no particular benefit.
> >
> >
> > auto x = localtime().hours>= 8 ?
> > "awake!"
> > :
> > "asleep, go away.";
> >
> > log( "I'm " ~ x );
> >
> >
> > If the expressions are complex I put them in functions.
> > 1) It hides and isolates details, which allows you to focus on the more
> > abstract aspects.
> > 2) It gives the expression a name and facilitates reuse.
>
> Agreed.
> But in practice I often end up beeing dubious about seemingly nice features
> like, precisely, the ternary operator. In languages that do not have such a
> nicety people end up writng eg:
> if (localtime().hours>= 8) x = awake;
> else x = "asleep, go away.";
> Apart from the very mild annoyance, I guess, of writing twice "x =", this is
> all gain: code is both more compact and legible.
> Precisely, because the ternary operator is a bit weird syntactically (and not
> that commonly needed and used in real code), people feel, just like you, the
> need to clarify it in code, finally using more vertical space. Note that the
> case here is the simplest possible, expressions being plain literal
> constants.
> I personly only consume 3 lines:
> auto x = (localtime().hours>= 8)
> ? "awake!"
> : "asleep, go away.";
> What do you think?
I always make a conscious effort to write succinct expressions. My rule is to
only use the ternary operator when it actually makes the code cleaner.
Why?
Branches should be conspicuous because they increase the number of code paths.
Exceptions are the other big source of code paths. This is, btw, why I think
that scope statements in D are just superb.
Re: More on Rust
On 02/10/11 13:49, Andrej Mitrovic wrote:
> On 2/10/11, Walter Bright 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:
> }
>
Even better:
switch( funcall() ) {
case "foo", "bar", "foobar", "barfoo": {
// complex code
break;
}
case "blue", "green": {
// complex code
break;
}
default:
// do nothing -- i like to comment defaults
}
Also often forgotten, that 'case' clauses take an argument list, not
just an expression. And yeah, in this case at least... it still fits in
80 columns. (I prefer 90 myself, but it's moot.)
-- Chris N-S
Re: More on Rust
On 2/11/11, Christopher Nicholson-Sauls wrote:
>
> Even better:
>
> switch( funcall() ) {
> case "foo", "bar", "foobar", "barfoo": {
> // complex code
> break;
> }
>
> case "blue", "green": {
> // complex code
> break;
> }
>
> default:
> // do nothing -- i like to comment defaults
> }
>
> Also often forgotten, that 'case' clauses take an argument list, not
> just an expression. And yeah, in this case at least... it still fits in
> 80 columns. (I prefer 90 myself, but it's moot.)
>
> -- Chris N-S
>
Damn I didn't know that! Thanks.
Re: More on Rust
On 10/02/2011 00:23, bearophile wrote: 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 Hum, this typestate concept actually looks quite interesting. I need to look in more detail, but it seems similar to some ideas I roughly considered several times before, about having a language being able to track which assertions are true for a given variable/value at any (or most) given points in code. I'm fond of ideas that could make a static type system even more powerful (more checking capabilities), without making it significantly more obtuse or verbose. I wonder if many improvements could be made on this area, enough even for it to be considered a significant step forward in language design/evolution. Oh how I wish that a day would have 48 hours... -- Bruno Medeiros - Software Engineer
Re: More on Rust language
I have found a slides pack, Rust All Hands Winter 2011, with some notes on typestates too: http://www.slideshare.net/pcwalton/rust-all-hands-winter-2011 And here there are some tests about macros too, search the word "macro": https://github.com/graydon/rust/tree/master/src/test/run-pass Bye, bearophile
Re: More on Rust language
On 11/3/2011 8:14 PM, bearophile wrote: Mark-compact (aka moving) collectors, where live objects are moved together to make allocated memory more compact. Note that doing this involves updating pointers’ values on the fly. This category includes semispace collectors as well as the more efficient modern ones like the .NET CLR’s that don’t use up half your memory or address space. C++ cannot support this without at least a new pointer type, because C/C++ pointer values are required to be stable (not change their values), so that you can cast them to an int and back, or write them to a file and back; this is why we created the ^ pointer type for C++/CLI which can safely point into #3-style compacting GC heaps. See section 3.3 of my paper (http://www.gotw.ca/publications/C++CLIRationale.pdf ) A Design Rationale for C++/CLI for more rationale about ^ and gcnew.< Tell me if I am wrong still. You're wrong still :-) How do you implement a moving GC in D if D has raw pointers? It can be done if the D compiler emits full runtime type info. It's a solved problem with GCs. D semantics doesn't allow the GC to automatically modify those pointers when the GC moves the data. Yes, it does. I've implemented a moving collector before designing D, and I carefully defined the semantics so that it could be done for D. Besides, having two pointer types in D would be disastrously complex. C++/CLI does, and C++/CLI is a failure in the marketplace. (I've dealt with multiple pointer types from the DOS daze, and believe me it is a BAD BAD BAD idea.)
Re: More on Rust language
Walter Bright: > You're wrong still :-) In this newsgroup I am used to being wrong several times every day :-) > It can be done if the D compiler emits full runtime type info. It's a solved > problem with GCs. I see, I will have to read more on this solution. > Besides, having two pointer types in D would be disastrously complex. Rust has three pointer types! :-) In Ada too I think there are three types of pointers. > (I've dealt with multiple > pointer types from the DOS daze, and believe me it is a BAD BAD BAD idea.) I am not sure, but I think the situation is very different here. Here it's only the type system that tells those pointers them apart, and restricts the kinds of operations you are allowed to do with them or changes the things they do. In Rust it's not the kind of memory they point to that tells what they are (as I presume was in DOS), here you are allowed to use one of the three kinds of pointers, as you like, for each kind of data you want. The difference is all in their semantics. I think this is very different from the DOS pointers situation. >From the examples of Rust code I've read, I have not seen any disaster >regarding the design of its pointers. They have implemented a not small >compiler with the language, so I think the pointer situation is not awful. Regarding pointer types, in D there are function pointers and function delegates, they are kind of two different kinds of pointers already. They increase language complexity, its usage, and require some conversion code, but they are not a disaster to use. Thank you for your answers, bye, bearophile
Re: More on Rust language
On 11/3/2011 9:14 PM, bearophile wrote: Regarding pointer types, in D there are function pointers and function delegates, they are kind of two different kinds of pointers already. And their only saving grace is they are not used that often, so the complexity is tolerable. This is not so for pointers.
Re: More on Rust language
On Thu, Nov 3, 2011 at 10:43 PM, Walter Bright wrote: > > How do you implement a moving GC in D if D has >> raw pointers? >> > > It can be done if the D compiler emits full runtime type info. It's a > solved problem with GCs. > > > D semantics doesn't allow the GC to automatically modify those >> pointers when the GC moves the data. >> > > Yes, it does. I've implemented a moving collector before designing D, and > I carefully defined the semantics so that it could be done for D. > > Besides, having two pointer types in D would be disastrously complex. > C++/CLI does, and C++/CLI is a failure in the marketplace. (I've dealt with > multiple pointer types from the DOS daze, and believe me it is a BAD BAD > BAD idea.) > Given the recent discussion on radical changes to GC and dtors, could someone please explain why having multiple pointer types is a bad idea?
Re: More on Rust language
On Friday, 9 May 2014 at 04:55:28 UTC, Caligo via Digitalmars-d wrote: On Thu, Nov 3, 2011 at 10:43 PM, Walter Bright wrote: How do you implement a moving GC in D if D has raw pointers? It can be done if the D compiler emits full runtime type info. It's a solved problem with GCs. D semantics doesn't allow the GC to automatically modify those pointers when the GC moves the data. Yes, it does. I've implemented a moving collector before designing D, and I carefully defined the semantics so that it could be done for D. Besides, having two pointer types in D would be disastrously complex. C++/CLI does, and C++/CLI is a failure in the marketplace. (I've dealt with multiple pointer types from the DOS daze, and believe me it is a BAD BAD BAD idea.) Given the recent discussion on radical changes to GC and dtors, could someone please explain why having multiple pointer types is a bad idea? It increases the complexity to reason about code. If the compiler does not give an helping hand, bugs are too easy to create. -- Paulo
Re: More on Rust language
On Friday, 4 November 2011 at 03:14:29 UTC, bearophile wrote:
Through Reddit I've found two introductions to the system
language Rust being developed by Mozilla. This is one of them:
http://marijnhaverbeke.nl/rust_tutorial/
This is an alpha-state tutorial, so some parts are unfinished
and some parts will probably change, in the language too.
Unfortunately this first tutorial doesn't discuss typestates
and syntax macros (yet), two of the most significant features
of Rust. The second tutorial discussed a bit typestates too.
Currently the Rust compiler is written in Rust and it's based
on the LLVM back-end. This allows it to eat its own dog food
(there are few descriptions of typestate usage in the compiler
itself) and the backend is efficient enough. Compared to DMD
the Rust compiler is in a earlier stage of development, it
works and it's able to compile itself but I think it's not
usable yet for practical purposes.
On the GitHub page the Rust project has 547 "Watch" and 52
"Fork", while DMD has 159 and 49 of them, despite Rust is a
quite younger compiler/software compared to D/DMD. So it seems
enough people are interested in Rust.
Most of the text below is quotations from the tutorials.
---
http://marijnhaverbeke.nl/rust_tutorial/control.html
Pattern matching
Rust's alt construct is a generalized, cleaned-up version of
C's switch construct. You provide it with a value and a number
of arms, each labelled with a pattern, and it will execute the
arm that matches the value.
alt my_number {
0 { std::io::println("zero"); }
1 | 2 { std::io::println("one or two"); }
3 to 10 { std::io::println("three to ten"); }
_ { std::io::println("something else"); }
}
There is no 'falling through' between arms, as in C—only one
arm is executed, and it doesn't have to explicitly break out of
the construct when it is finished.
The part to the left of each arm is called the pattern.
Literals are valid patterns, and will match only their own
value. The pipe operator (|) can be used to assign multiple
patterns to a single arm. Ranges of numeric literal patterns
can be expressed with to. The underscore (_) is a wildcard
pattern that matches everything.
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.
A powerful application of pattern matching is destructuring,
where you use the matching to get at the contents of data
types. Remember that (float, float) is a tuple of two floats:
fn angle(vec: (float, float)) -> float {
alt vec {
(0f, y) when y < 0f { 1.5 * std::math::pi }
(0f, y) { 0.5 * std::math::pi }
(x, y) { std::math::atan(y / x) }
}
}
A variable name in a pattern matches everything, and binds that
name to the value of the matched thing inside of the arm block.
Thus, (0f, y) matches any tuple whose first element is zero,
and binds y to the second element. (x, y) matches any tuple,
and binds both elements to a variable.
Any alt arm can have a guard clause (written when EXPR), which
is an expression of type bool that determines, after the
pattern is found to match, whether the arm is taken or not. The
variables bound by the pattern are available in this guard
expression.
Record patterns
Records can be destructured on in alt patterns. The basic
syntax is {fieldname: pattern, ...}, but the pattern for a
field can be omitted as a shorthand for simply binding the
variable with the same name as the field.
alt mypoint {
{x: 0f, y: y_name} { /* Provide sub-patterns for fields */ }
{x, y} { /* Simply bind the fields */ }
}
The field names of a record do not have to appear in a pattern
in the same order they appear in the type. When you are not
interested in all the fields of a record, a record pattern may
end with , _ (as in {field1, _}) to indicate that you're
ignoring all other fields.
Tags
Tags [FIXME terminology] are datatypes that have several
different representations. For example, the type shown earlier:
tag shape {
circle(point, float);
rectangle(point, point);
}
A value of this type is either a circle¸ in which case it
contains a point record and a float, or a rectangle, in which
case it contains two point records. The run-time representation
of such a value includes an identifier of the actual form that
it holds, much like the 'tagged union' pattern in C, but with
better ergonomics.
Tag patterns
For tag types with multiple variants, destructuring is the only
way to get at their contents. All variant constructors can be
used as patterns, as in this definition of area:
fn area(sh: shape) -> float {
alt sh {
circle(_, size) { std::math::pi * size * size }
rectangle({x, y}, {x: x2, y: y2}) { (x2 - x) * (y2 - y)
}
}
}
-
Re: More on Rust language
It increases the complexity to reason about code. No, that's wrong. If the compiler does not give an helping hand, bugs are too easy to create. Usually a type system is used to increase safety...
Re: More on Rust language
Am 09.05.2014 21:53, schrieb Araq: It increases the complexity to reason about code. No, that's wrong. Why it is wrong? Even you ever seen a programmer reason about unique pointers, shared pointers, weak pointers, naked pointers, references and cyclic data structures without mistakes? In any language that provide them? If the compiler does not give an helping hand, bugs are too easy to create. Usually a type system is used to increase safety... That is why Rust provides a type system that knows about pointer types, lifetimes and usage dataflow. Because in languages that don't go that far, the desired outcome is not always the best. -- Paulo
Re: More on Rust language
Rust is quite seductive (own point of view of course) in its "traits" system. They've found the right median line between OOP and TMP. I mean it's a realy nice concept.
Re: More on Rust language
Le 10/05/2014 11:35, Douglas Peterson a écrit : Rust is quite seductive (own point of view of course) in its "traits" system. They've found the right median line between OOP and TMP. I mean it's a realy nice concept. Have you a direct link about traits? Cause I am almost unable to see their tutorials (infinite loading time).
Re: More on Rust language
It increases the complexity to reason about code. No, that's wrong. Why it is wrong? Because it is much harder to reason about the same things without type system support.
Re: More on Rust language
On Saturday, 10 May 2014 at 11:43:29 UTC, Xavier Bigand wrote: Le 10/05/2014 11:35, Douglas Peterson a écrit : Rust is quite seductive (own point of view of course) in its "traits" system. They've found the right median line between OOP and TMP. I mean it's a realy nice concept. Have you a direct link about traits? Cause I am almost unable to see their tutorials (infinite loading time). http://static.rust-lang.org/doc/master/rust.html#traits
