dmd 2.029 release

[Walter Bright]

This is a major revision to Phobos, including Andrei's revolutionary new
range support.

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

[Simen Kjaeraas]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Butbutbut... I've just barely managed to install 2.028 yet.

Great work! Can't wait to try out the new ranges.

--
Simen

[BCS]

Hello Walter,

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Cool template function literals sounds interesting

[bearophile]

Post by BCS
Cool template function literals sounds interesting

May I have one example of them?
I am looking in the docs, but I am not finding anything...

Bye,
bearophile

[Walter Bright]

Post by bearophile

Post by BCS
Cool template function literals sounds interesting

May I have one example of them?
I am looking in the docs, but I am not finding anything...

void foo(alias f)()
{
f(3, 4);
}

foo!((x,y){return x * y;))();

[bearophile]

Post by Walter Bright
void foo(alias f)()
{
f(3, 4);
}
foo!((x,y){return x * y;))();

I have tried:

import std.stdio: writeln;
void foo(alias f)() {
f(3, 4);
}
void main() {
foo!( (x, y) { writeln(x * y); } )();
}

And it works, printing 12 :-) Very cute.
This is able to simplify some of the code of (D1) dlibs :-)

I didn't even know that lambda delegates in D2 can now infer the type of their input argument, so you can use (x, y) instead of (int x, int y). Can you tell me when this was changed? :-)

Bye,
bearophile

[bearophile]

In D1 I have written a very hairy (but not too much long) apply() function, that given a function and some arguments, returns the result of the function applied to them. (apply() is a basic higher-order thing common in most functional languages).

So now I'm playing with this new toy of D2, not using it in a serious way yet, and I have written:

import std.stdio: writeln;
auto apply(alias f, TyArgs...)(TyArgs args) {
return f(args);
}
void main() {
writeln( apply!( (x, y) { return x * y; } )(3, 4) );
}

But when I compile it the compile spits out at compile-time:
Assertion failure: '0' on line 935 in file 'glue.c'

Bye,
bearophile

[Andrei Alexandrescu]

Post by bearophile
In D1 I have written a very hairy (but not too much long) apply() function, that given a function and some arguments, returns the result of the function applied to them. (apply() is a basic higher-order thing common in most functional languages).
import std.stdio: writeln;
auto apply(alias f, TyArgs...)(TyArgs args) {
return f(args);
}
void main() {
writeln( apply!( (x, y) { return x * y; } )(3, 4) );
}
Assertion failure: '0' on line 935 in file 'glue.c'
Bye,
bearophile

Your code should work as expected. (Also, right off the bat, any
assertion failure in the compiler is a bug.) Could you submit to bugzilla?

Andrei

[Walter Bright]

Post by bearophile
Assertion failure: '0' on line 935 in file 'glue.c'

All assertion failures are compiler bugs and belong in bugzilla:

http://d.puremagic.com/issues/show_bug.cgi?id=2863

[Walter Bright]

Post by bearophile
I didn't even know that lambda delegates in D2 can now infer the type
of their input argument, so you can use (x, y) instead of (int x, int
y). Can you tell me when this was changed? :-)

That change *is* the template function literals, and they are only valid
as template arguments.

[tama]

On Mon, 20 Apr 2009 18:12:16 +0900, Walter Bright

Post by Walter Bright

Post by bearophile

Post by BCS
Cool template function literals sounds interesting

May I have one example of them?
I am looking in the docs, but I am not finding anything...

void foo(alias f)()
{
f(3, 4);
}
foo!((x,y){return x * y;))();

void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();

This code doesn't work(compile error). But, following code works.

void bar(alias f)()
{
writefln(f("bar"));
}
bar!((str) { return str; })();

Is this a bug?

[bearophile]

Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).

To me the following works:

import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}

Bye,
bearophile

[tama]

Post by bearophile

Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).

import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}

I see.

I tested following code.

writefln(3 * 4);

This code doesn't work in the first place:-<
Sorry, it didn't matter.

[Denis Koroskin]

Post by tama

Post by bearophile

Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).

import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}

I see.
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<
Sorry, it didn't matter.

writefln now expects a string as a first argument.
Use writeln() if you need no formattings, it is both faster and safer.

[tama]

Post by Denis Koroskin
writefln now expects a string as a first argument.
Use writeln() if you need no formattings, it is both faster and safer.

To one's shame, I didn't know detailed writef/writefln spec.
I checked D2 changelog and founded it at version 2.006 and 2.029.

Thanks!

[Walter Bright]

Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<

Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.

If it isn't, use writeln instead.

[Russell Lewis]

Post by Walter Bright

Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<

Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.
If it isn't, use writeln instead.

I just hit the same breakage. :(

Since the compiler can detect this situation statically, shouldn't
Phobos just statically redirect the call to writeln() ?

[Andrei Alexandrescu]

Post by Russell Lewis

Post by Walter Bright

Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<

Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.
If it isn't, use writeln instead.

I just hit the same breakage. :(
Since the compiler can detect this situation statically, shouldn't
Phobos just statically redirect the call to writeln() ?

It did for a while. For cleanliness purposes, I thought it was about
time to eliminate that. Also, extraneous arguments passed to writef will
be ignored, not printed with default formatting.

Andrei

[bearophile]

Post by Andrei Alexandrescu
extraneous arguments passed to writef will
be ignored, not printed with default formatting.

That sounds bad:
=> "Errors should never pass silently."
It's better to raise a compilation error. (And if that's not possible, then an exception at run-time. But a compilation error is much better).

Bye,
bearophile

[Andrei Alexandrescu]

extraneous arguments passed to writef will be ignored, not printed
with default formatting.

That sounds bad: => "Errors should never pass silently." It's better
to raise a compilation error. (And if that's not possible, then an
exception at run-time. But a compilation error is much better).

If it were an error, I wouldn't let it go. A good use case is string
tables - a formatted message may or may not use all of the available
information.

Andrei

[bearophile]

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.

Bye,
bearophile

[BCS]

Reply to bearophile,

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.
Bye,
bearophile

Then there need to be a way for the format string to use an argument without
generating output for it because as Andrei is saying, there are real world
cases where not using all the args is *normal* and not an error.

One option would be to not throw an error if the format string uses indexing
formats (e.i. out of order formatting)

[Andrei Alexandrescu]

Post by BCS
Reply to bearophile,

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.
Bye,
bearophile

Then there need to be a way for the format string to use an argument
without generating output for it because as Andrei is saying, there are
real world cases where not using all the args is *normal* and not an error.
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

Andrei

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message

Post by Andrei Alexandrescu

Post by BCS
Reply to bearophile,

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.
Bye,
bearophile

Then there need to be a way for the format string to use an argument
without generating output for it because as Andrei is saying, there are
real world cases where not using all the args is *normal* and not an error.
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

That would be far too clumbsy, unless you made it into two separate
functions.

For instance (psuedocode):
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error

[BCS]

Reply to Nick,

Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message

Post by Andrei Alexandrescu

Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error

They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.

[Nick Sabalausky]

"BCS" <ao at pathlink.com> wrote in message

Post by BCS
Reply to Nick,

Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message

Post by Andrei Alexandrescu

Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error

They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.

I was just using names for illustrative purposes. Also, I was under the
impression that printf-style "get the next arg" formatting codes were the
only ones writef supported. Is this not so?

[Andrei Alexandrescu]

Post by Nick Sabalausky
"BCS" <ao at pathlink.com> wrote in message

Post by BCS
Reply to Nick,

Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message

Post by Andrei Alexandrescu

Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error

They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.

I was just using names for illustrative purposes. Also, I was under the
impression that printf-style "get the next arg" formatting codes were the
only ones writef supported. Is this not so?

Since a few versions ago writef supports positional arguments with Posix
syntax.

Andrei

[Georg Wrede]

Post by Andrei Alexandrescu

Post by Nick Sabalausky

Post by BCS
Reply to Nick,

Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message

Post by Andrei Alexandrescu

Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)

Yah, that's an option I considered. Maybe it's the best way to go.

That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error

They are in order but are listed by name so the error doesn't throw.
The case where the error would be thrown is where the only format
strings used are the "get the next arg" kind.

I was just using names for illustrative purposes. Also, I was under
the impression that printf-style "get the next arg" formatting codes
were the only ones writef supported. Is this not so?

Since a few versions ago writef supports positional arguments with Posix
syntax.
Andrei

Positional format specifications really make a huge difference,
especially where one needs to have the user interface in several
languages. Thanks for them!!

Now, for the case without positional format specifications, we could
(and I guess, should) have a solution to "the wrong number of arguments"
problem. If we have:

- a non-printing format spec
- a munch-the-remaining-ones format spec
- an ignore-too-few-arguments format spec

we could cover all the needed cases.

The first one lets you use one parameter without printing it. (Maybe you
don't want to print the middle part of somebody's name.) The second is
used when you don't want to print possibly many remaining arguments, say
the address of someone, or the country.

The last one, is for the case where you use a single format string in
several contexts, some of which you suspect may not contain enough
information to be formally correct, but where you are satisfied to print
an empty string '' (that is, not print anything) for them.

This situation might arise when the format string originates from
outside the program.

** When none of the latter two are used, and there is the wrong number
of arguments, I think a runtime exception should be thrown.

The only time where I think a compile time error is warranted, is when
the format string is a string literal, with the wrong number of arguments.


The programmer may put the ignore-too-few-arguments format spec anywhere
in the format string. Its effect starts from that point on.

[Andrei Alexandrescu]

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.

Well at most you could say it's error-prone, something that is easier to
argue. The problem is that forcing it into an error makes quite a number
of valid uses impossible. An example is a logging application that
provides you a number of pieces of information (date, time, message,
etc.) and you get to specify how they should be formatted. Oftentimes
you'd choose to ignore some data.

Andrei

[Russell Lewis]

Post by Andrei Alexandrescu

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.

Well at most you could say it's error-prone, something that is easier to
argue. The problem is that forcing it into an error makes quite a number
of valid uses impossible. An example is a logging application that
provides you a number of pieces of information (date, time, message,
etc.) and you get to specify how they should be formatted. Oftentimes
you'd choose to ignore some data.
Andrei

Fair enough. But then let's split off a version of the function which
allows unused arguments. For most users, in most cases, unused
arguments are indicative of an error.

Case in point: I have been bitten by this perhaps half a dozen times
*already* porting older code. This code used to work fine:

writefln("The value is: %d", myVar, ". Do something!");

Now, it interprets the trailing string as an unused argument, and
ignores it (silently). Ugh.

Ofc, looking back, I don't like that old coding style...I'm migrating
back more to C-style (give the whole format string first). But the fact
that I had a *silent* error was frustrating.

Russ

[Lutger]

Russell Lewis wrote:

...

Post by Russell Lewis
Case in point: I have been bitten by this perhaps half a dozen times
writefln("The value is: %d", myVar, ". Do something!");

...

I bet a lot of to-be-ported D code will have this bug, I know my code will.
When you want to print a format string this way - last argument(s) simply
appended, it saves you two characters typing. When something saves any
characters typing and produces the same result, programmers will do that.

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message

Post by bearophile

Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.

It's an error. It will lead to troubles.

Sometimes it is an error, but there are times when it isn't:

Suppose you're writing a reporting module for an employee database:

---------------------
ID: 3234
Last: Doe
First: John
Phone: [phone]
Zip: 90210

ID: 7642
Last: Smith
Etc...
---------------------

And you want the admins to be able to define their own reports:

---------------------
Privileged Report:
For Each Person: "ID #{ID}\nName: {First} {Last}\nPhone: {Phone}\nZip:{Zip}"

Unprivileged Report:
For Each Person: "Name: {Last}, {First}\nContact Info Classified"

Call List In Psuedo-Japanese:
For Each Person Where Name="Smith": "SmithSan {LoopIndex}'s DenwaBango:
{Phone}"
---------------------

So then the report creation code:

---------------------
foreach(int i, Person p; people.subset(customReport.whereClause))
writefln(customReport.formatStr, i, p.id, p.first, p.last, p.phone,
p.zip);
---------------------

That would be very difficult/limiting if every arg had to be used in the
format string.

(Incidentally, this example also demonstrates why I consider C#/Tango-style
string formatting superior to C/Phobos-style)

[Daniel Keep]

Post by bearophile

Post by BCS
Cool template function literals sounds interesting

May I have one example of them?
I am looking in the docs, but I am not finding anything...
Bye,
bearophile
alias (T)(T a, T b) { return (a+b)/2.0; } average;

Haven't had a chance to TRY that yet, mind you. :P

-- Daniel

[Daniel Keep]

Post by Daniel Keep

Post by bearophile

Post by BCS
Cool template function literals sounds interesting

May I have one example of them?
I am looking in the docs, but I am not finding anything...
Bye,
bearophile
alias (T)(T a, T b) { return (a+b)/2.0; } average;

Haven't had a chance to TRY that yet, mind you. :P
-- Daniel

(Sees Walter's post)

Guess not. :P

-- Daniel

[Georg Wrede]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Ooohhh, just half way through the change log, and already breathless!!!

[Saaa]

Using D1 feels especially retarded today :(

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

[Georg Wrede]

Post by Saaa
Using D1 feels especially retarded today :(

Don't cry now. :-)
Soon you'll be using D2 for work, and cry when you see the D3 change log...

[Tomas Lindquist Olsen]

Post by Saaa
Using D1 feels especially retarded today :(

Why retarded ?

[Georg Wrede]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

The documentation for completeSort in std.algorithm says:

Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.

I wonder what it should be.

[Andrei Alexandrescu]

Post by Georg Wrede

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.
I wonder what it should be.

Sorry, what was I thinking? I think (without being sure) that the
complexity of completeSort is O(rhs.length * log(t)) in the
best case, and O(t * log(t)) in the worst case, where t = lhs.length +
rhs.length.


Andrei

[Andrei Alexandrescu]

Post by Andrei Alexandrescu

Post by Georg Wrede

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.
I wonder what it should be.

Sorry, what was I thinking? I think (without being sure) that the
complexity of completeSort is O(rhs.length * log(t)) in the
best case, and O(t * log(t)) in the worst case, where t = lhs.length +
rhs.length.

I revise that. Best case, there's temporary memory to allocate and then
the complexity is that of sorting rhs plus merge lhs and rhs using extra
memory. That is O(lhs.length + rhs.length * log(rhs.length)).

Worst case, there's no temporary memory available so we need to sort the
whole thing. That means O((lhs.length + rhs.length) * log(rhs.length +
rhs.length)).

I committed the fixed module.


Andrei

[dsimcha]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Two small issues I've just run into that might warrant a quick update:

Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.

Also, when using std.string, I get the following linker errors on the Win32 build:


Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya

[dsimcha]

== Quote from dsimcha (dsimcha at yahoo.com)'s article

Post by dsimcha
== Quote from Walter Bright (newshound1 at digitalmars.com)'s article

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.
Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya

Never mind on the linker error. That was caused by me forgetting to recompile
parts of my code. The random thing looks legit, though.

[Andrei Alexandrescu]

Post by dsimcha
== Quote from dsimcha (dsimcha at yahoo.com)'s article

Post by dsimcha
== Quote from Walter Bright (newshound1 at digitalmars.com)'s article

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.
Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya

Never mind on the linker error. That was caused by me forgetting to recompile
parts of my code. The random thing looks legit, though.

Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand()
entirely from this release, but Walter pointed out it would break too
much code. So I left rand() and rand_seed() as deprecated. Now I only
left rand() deprecated so at least the static constructor works.


Andrei

[Walter Bright]

Post by Andrei Alexandrescu
Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand()
entirely from this release, but Walter pointed out it would break too
much code. So I left rand() and rand_seed() as deprecated. Now I only
left rand() deprecated so at least the static constructor works.

I think the right fix for that is for the compiler to not complain about
deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.

[Walter Bright]

http://d.puremagic.com/issues/show_bug.cgi?id=2864

[Andrei Alexandrescu]

Post by Walter Bright

Post by Andrei Alexandrescu
Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate
rand() entirely from this release, but Walter pointed out it would
break too much code. So I left rand() and rand_seed() as deprecated.
Now I only left rand() deprecated so at least the static constructor
works.

I think the right fix for that is for the compiler to not complain about
deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.

Reading this, I thought "No chance Walter will ever do this" until I saw
the poster's name :o).

Andrei

[Walter Bright]

Post by Andrei Alexandrescu

Post by Walter Bright
I think the right fix for that is for the compiler to not complain
about deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.

Reading this, I thought "No chance Walter will ever do this" until I saw
the poster's name :o).

It is consistent with the ideas behind private access. Presumably the
person working on the module knows what they're doing, no need to hide
it from himself.

[Craig Black]

I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!

-Craig

[superdan]

Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig

holy guacashit this works.

import std.algorithm;
import std.range;
import std.stdio;

void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}

i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.

[downs]

Post by superdan

Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig

holy guacashit this works.
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}
i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.

Poop is funny! :)

[Andrei Alexandrescu]

Post by superdan

Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig

holy guacashit this works.
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}
i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.

Thanks... I guess :o). Any chance you could submit the issues to
bugzilla? I think the problem with string arrays is already known, but I
need a memento to make writeln work with ranges.

Andrei

[Andrei Alexandrescu]

Post by Craig Black
I like very much the direction D2 is going now. Language refactoring
and enhancements driven by the goal of more elegant implementation of
standard libraries. This approach seems very practical and promising.
Thank you very much and keep it up!
-Craig

Thanks. Walter pointed out to me something interesting - STL is
non-intuitive. That doesn't make it any less true (as a pursuit of the
most generic incarnation of fundamental structs and algos). It's
non-intuitive the same way complex numbers and relativity theory are
non-intuitive.

No language has ever managed to comprehend STL by sheer chance. (This in
spite of e.g. C# adding a boatload of new features with each release.)
There are two that can express it at all: C++ and D. Both C++ and D had
to be changed to allow STL to exist, and became better languages as a
result. The range shtick and D's support for lambdas is taking STL
support to a whole new level.

The downside is, it's rather difficult to explain the STL to anyone
using other languages and wanting to just figure what the STL buzz is
all about.


Andrei

[Georg Wrede]

Post by Andrei Alexandrescu

Post by Craig Black
I like very much the direction D2 is going now. Language refactoring
and enhancements driven by the goal of more elegant implementation of
standard libraries. This approach seems very practical and
promising. Thank you very much and keep it up!
-Craig

Thanks. Walter pointed out to me something interesting - STL is
non-intuitive. That doesn't make it any less true (as a pursuit of the
most generic incarnation of fundamental structs and algos). It's
non-intuitive the same way complex numbers and relativity theory are
non-intuitive.
No language has ever managed to comprehend STL by sheer chance. (This in
spite of e.g. C# adding a boatload of new features with each release.)
There are two that can express it at all: C++ and D. Both C++ and D had
to be changed to allow STL to exist, and became better languages as a
result. The range shtick and D's support for lambdas is taking STL
support to a whole new level.
The downside is, it's rather difficult to explain the STL to anyone
using other languages and wanting to just figure what the STL buzz is
all about.

I wrote my MSc thesis about the STL. I think the conceptual idea was
clean and clear, and at the time it was reasonably easy to explain it to
even the professors. ;-)

Today, however, and especially with the advanced implementation we have
here in D, if someone has no prior knowledge of the STL way of thinking,
it may be really hard to get them to 'get it'. There are too many trees
up front to grasp the forest.

What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library
really sucks at introducing the STL on a conceptual level. Even worse,
that is actually the only thing it *should* do. Everyting else is optional.

[Leandro Lucarella]

Post by Georg Wrede
What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library
really sucks at introducing the STL on a conceptual level. Even worse, that is
actually the only thing it *should* do. Everyting else is optional.

You should improve it then =)

[Georg Wrede]

Walter Bright wrote:

In std.array, the example for back() is the same as for front().


The example for put() seems to be correct (and put() behaves
accordingly), however, the asserted results are not what the reader
would expect.

If we are verbose enough to explain the dot notation here, then it would
be prudent to elaborate a little as to the point of put(), and possibly
the example (or the explanation) could include a use case.

[Russell Lewis]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Was fwritefln() removed intentionally? Or should I write up a Bugzilla?
I didn't noteice a mention in changelog.

[Andrei Alexandrescu]

Post by Russell Lewis

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Was fwritefln() removed intentionally? Or should I write up a Bugzilla?
I didn't noteice a mention in changelog.

Sorry. It was removed intentionally along with all functions that
manipulate FILE* directly.

Its functional equivalent is File.writefln. If all you have is a handle,
use File.wrapFile(fhandle).writefln.


Andrei

[annoyed]

It's in dmd-v2.026/src/phobos/std/stdio.d:void fwritefln(FILE* fp, ...)

but I cannot find it in 2.029.

[unknown]

Post by annoyed
It's in dmd-v2.026/src/phobos/std/stdio.d:void fwritefln(FILE* fp, ...)
but I cannot find it in 2.029.

It was removed, use File.writefln() instead. std.stdio has been rewritten so you might want to take a look at the docs.

Andrew

[Stewart Gordon]

Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.

Stewart.

[Walter Bright]

Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.

As far as I know, it is current. Everything got checked in.

[BCS]

Hello Walter,

Post by Walter Bright

Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.

As far as I know, it is current. Everything got checked in.

I think he was asking about the otherway (not that I known why)

[Walter Bright]

Post by BCS
I think he was asking about the otherway (not that I known why)

I think he'll need to be more specific!

[Unknown W. Brackets]

Well, there's push (svn commit) and pull (svn up), so he must mean one
or the other...

-[Unknown]

Post by Walter Bright

Post by BCS
I think he was asking about the otherway (not that I known why)

I think he'll need to be more specific!

[Stewart Gordon]

Post by Walter Bright

Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.

As far as I know, it is current. Everything got checked in.

So how has the fix for
http://d.puremagic.com/issues/show_bug.cgi?id=2580
(and probably others) not been included?

Stewart.

[Max Samukha]

On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!

file:///C:/dmd/html/d/phobos/std_range.html#cons
Looks like bug 2676 was fixed in 2.027

[Max Samukha]

On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha

Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons

http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons

Post by Max Samukha
Looks like bug 2676 was fixed in 2.027

[Andrei Alexandrescu]

Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha

Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons

http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons

Post by Max Samukha
Looks like bug 2676 was fixed in 2.027

Thanks. I uncommented the unittest, updated the doc, and checked in.

Andrei

[Max Samukha]

On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu

Post by Andrei Alexandrescu

Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha

Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons

http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons

Post by Max Samukha
Looks like bug 2676 was fixed in 2.027

Thanks. I uncommented the unittest, updated the doc, and checked in.
Andrei

A couple more minor doc issues:
http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of
"the popFront" need to be corrected to "the next".

On the std.algorithm page, the examples for "map" and "filter" don't
compile due to the fixed size array in equal().

The example for "bringToFront" is outdated.

The comments for "remove": "If $(s =" -> "If $(D s ="

[Brad Roberts]

Post by Max Samukha
On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu

Post by Andrei Alexandrescu

Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha

Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons

http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons

Post by Max Samukha
Looks like bug 2676 was fixed in 2.027

Thanks. I uncommented the unittest, updated the doc, and checked in.
Andrei

http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of
"the popFront" need to be corrected to "the next".
On the std.algorithm page, the examples for "map" and "filter" don't
compile due to the fixed size array in equal().
The example for "bringToFront" is outdated.
The comments for "remove": "If $(s =" -> "If $(D s ="

Please file a bug report. Posts here are are good way for issues to
fall through the cracks.

Thanks,
Brad

[Lars T. Kyllingstad]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...

I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?

I admit I don't know much about these things, and what I'm going to say
next may not make sense at all, but here goes:

x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.

I know it is possible to run the 32-bit compiler (and the executables it
produces) on a 64-bit operating system, but it isn't possible to link
against 64-bit libraries. This means that one has to install and
maintain 32-bit versions of all the libraries one wants to use, and
those are, in general, not available through the repositories of most
64-bit distros.

-Lars

[Frits van Bommel]

Post by Lars T. Kyllingstad

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I admit I don't know much about these things, and what I'm going to say
x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.

It's not quite that simple. It's not a full superset; some x86 instructions are
not valid x86-64 instructions.
For example, I think 'inc' was removed to make place for prefixes that set some
flags for the next instruction and allow it to use the extra registers r8-r15.

[Daniel Keep]

Post by Lars T. Kyllingstad

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I admit I don't know much about these things, and what I'm going to say
x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.

I'm pretty sure that 64-bit code is binary incompatible with 32-bit
code. For example:

struct Foo { void* ptr; }

Is a different size for 32-bit and 64-bit code.

Post by Lars T. Kyllingstad
I know it is possible to run the 32-bit compiler (and the executables it
produces) on a 64-bit operating system, but it isn't possible to link
against 64-bit libraries. This means that one has to install and
maintain 32-bit versions of all the libraries one wants to use, and
those are, in general, not available through the repositories of most
64-bit distros.

This is because the OS puts the CPU into a 32-bit compatible mode, but
it can't magic away the differences between 32-bit and 64-bit code.

Post by Lars T. Kyllingstad
-Lars

The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.

-- Daniel

[Frits van Bommel]

Post by Daniel Keep

Post by Lars T. Kyllingstad

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...

[snip]

Post by Daniel Keep
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.

The state for D2 is currently "very broken", AFAIK.

[Lutger]

Daniel Keep wrote:

...

Post by Daniel Keep

-Lars

The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel

if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!

[Don]

Post by Lutger
...

Post by Daniel Keep

-Lars

The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel

if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!

They're just part of the standard OBJ file format. Nothing to do with
code generation. Much more fun is:
$ cd src/dmd
$ grep "goto " * -R

[Lutger]

Post by Don

Post by Lutger
...

Post by Daniel Keep

-Lars

The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel

if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!

They're just part of the standard OBJ file format. Nothing to do with
$ cd src/dmd
$ grep "goto " * -R

you forgot " | less" there, what the hell...this code can't be human.

[Walter Bright]

Post by Lutger
what the hell...this code can't be human.

I was replaced by Colossus years ago.

[Georg Wrede]

Post by Walter Bright

Post by Lutger
what the hell...this code can't be human.

I was replaced by Colossus years ago.

Michael A. Jackson wouldn't approve 1175 gotos in 113 files.

[Don]

Post by Georg Wrede

Post by Walter Bright

Post by Lutger
what the hell...this code can't be human.

I was replaced by Colossus years ago.

Michael A. Jackson wouldn't approve 1175 gotos in 113 files.

It'd be really funny to pass it through one of those "code quality"
metrics, one of the ones with a ridiculously heavy penalty for using
goto. I think it'd tell you that DMD source is almost the lowest-quality
code on the planet. <g>

Actually, looking through the DMD source it becomes obvious that goto is
really not a problem at all. The lack of comments is much more of a
problem. (Especially with files with names like "e2ir.c". What the heck
is "fltables.c", "cdxxx.c", "elxxx.c" ?). Even so, it's mostly not that
difficult to understand.

[Andrei Alexandrescu]

Post by Lars T. Kyllingstad

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?

I would kill for a 64-bit Linux DMD. I think it could take a lot of ways
of coding to a whole new level. Sean and I have also been discussing how
to integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.


Andrei

[Lars T. Kyllingstad]

Post by Lars T. Kyllingstad

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?

I would kill for a 64-bit Linux DMD. [...]

Who does one have to kill to get a 64-bit compiler around here? :)

But seriously, now that the language itself is stabilising, I would
consider this a major priority for further development of DMD. 64 bits
is the (immediate) future.

-Lars

[Leandro Lucarella]

Post by Lars T. Kyllingstad

This is a major revision to Phobos, including Andrei's revolutionary new range
support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked for this
before, but is making a 64-bit Linux version of DMD a lot of work?

I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of
coding to a whole new level. Sean and I have also been discussing how to
integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.

Can you elaborate on that?

Thanks.

[Andrei Alexandrescu]

Post by Leandro Lucarella

Post by Lars T. Kyllingstad

This is a major revision to Phobos, including Andrei's revolutionary new range
support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked for this
before, but is making a 64-bit Linux version of DMD a lot of work?

I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of
coding to a whole new level. Sean and I have also been discussing how to
integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.

Can you elaborate on that?

Not much time, but in short: Memory-mapped files are not a pure library
thing, they are core because they manipulate the address space. So they
are quite like memory allocation. Unmapping files by hand is as unsafe
as calling delete. So memory mapped files must be integrated with the
collector: you map a file by hand, and the garbage collector closes it
when there are no more references to the memory mapped for the file.

The programming model is pretty cool - in 32 bit I always need to mind
the address space because it's so densely populated. In 64 bits I can
map all of my data files in memory and let the paging system and the
garbage collector take care of the rest.


Andrei

[Lutger]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Thanks so much, looking good!

The lambda template parameters: very cool.

[Don]

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Missing from the changelog:

From 2.208:
2804 Impure nested functions should be legal inside pure functions

From 2.209:
std.math:
Intrinsics std.math.yl2x and yl2xp1 added. Improves performance of
std.math.log() and similar functions (and they are now pure nothrow).

(Yes, I know, not very exciting compared to Andrei's new Phobos <g>).

[bearophile]

Post by Don
2804 Impure nested functions should be legal inside pure functions

Very good. Now that little example works:

import std.c.stdio: printf;
import std.conv: to;

pure int double_sqr(int x) {
int y, z;
void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

The outout is correct:
4 * x * x = 400


"Cleaned up" ASM produced by DMD V.2.029, -O -release -inline:

double_sqr:
push EAX
mov ECX,EAX
mov [ESP],0
mov [ESP],ECX
imul EAX,[ESP]
mov EDX,EAX
mov [ESP],EAX
mov EAX,ECX
mov [ESP],ECX
imul EAX,[ESP]
add EDX,EAX
mov [ESP],EAX
mov EAX,EDX
pop ECX
ret

double_sqr.do_sqr:
mov ECX,[EAX]
imul ECX,[EAX]
mov [EAX],ECX
ret

main:
L0: sub ESP,014h
cmp dword ptr 018h[ESP],2
jne L21
mov EDX,01Ch[ESP]
mov EAX,018h[ESP]
mov EAX,8[EDX]
mov EDX,0Ch[EDX]
push EDX
push EAX
call near ptr parseString
jmp short L26
L21: mov EAX,0Ah
L26: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf

As you can see there's only one call to double_sqr in the main program, so the pure semantics is working here.

You can also see do_sqr is inlined into double_sqr. But the asm code inside double_sqr looks very hairy and long, and double_sqr itself isn't inlined in the main.

Bye,
bearophile

[bearophile]

I have tried the following code:

import std.c.stdio: printf;
import std.conv: to;

nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

The compiler spits the following error:

pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr' is nothrow yet may throw

but I don't understand why. What are the things inside it that can throw an exception?

Bye,
bearophile

[bearophile]

I have also tested the semantics of nested function purity:

import std.c.stdio: printf;
import std.conv: to;

pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

Compiled without inlining:
-O -release

double_sqr.sqr:
mov EAX,4[ESP]
imul EAX,EAX
ret 4

double_sqr:
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret

main:
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf

There's one call to double_sqr but unfortunately two to double_sqr.sqr.

Bye,
bearophile

[Don]

Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
-O -release
mov EAX,4[ESP]
imul EAX,EAX
ret 4
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile

Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.

I'm not sure that nested pure member functions should be legal.

[Don]

Post by Don

Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
-O -release
mov EAX,4[ESP]
imul EAX,EAX
ret 4
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile

Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.

The bug is bugzilla 2807.

Post by Don
I'm not sure that nested pure member functions should be legal.

And it turns out that sqr() isn't actually pure, in the same way that it
wasn't nothrow in your first example. The 'pure' marker is silently
being ignored. If you put the 'pure' at the end, you get bug 2807.

--

[bearophile]

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.

It's not fully equivalent to moving it out of the function because once you pull it out you add a name to the outer namespace: nested functions are useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.

pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}

Thank you,
bye,
bearophile

[Don]

Post by bearophile

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.

It's not fully equivalent to moving it out of the function because once you pull it out you add a name to the outer namespace: nested functions are useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile

That's true, but it seems quite difficult to get right. A pure nested
function can in theory access immutable members in the outer function --
but must not access the parameters of the outer function.
If there are no immutable members in the outer function, the compiler
would ideally convert it into an external pure function, so that it
doesn't need a frame pointer to the outer function. But it would need
error messages for any use of mutable outer function members. Etc.
It seems quite a lot of work for something of very limited use.
Making it into a external, private pure function is almost the same.

[Tomas Lindquist Olsen]

Post by Don

Post by bearophile

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.

It's not fully equivalent to moving it out of the function because once
you pull it out you add a name to the outer namespace: nested functions are
useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
?pure int foo(int y) { return y * y; }
?return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile

That's true, but it seems quite difficult to get right. A pure nested
function can in theory access immutable members in the outer function -- but
must not access the parameters of the outer function.
If there are no immutable members in the outer function, the compiler would
ideally convert it into an external pure function, so that it
doesn't need a frame pointer to the outer function. But it would need error
messages for any use of mutable outer function members. Etc.
It seems quite a lot of work for something of very limited use.
Making it into a external, private pure function is almost the same.

why not just make it a static pure nested function? or is that no
longer proper D2 ?

[Michel Fortin]

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.

What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.

[Daniel Keep]

Post by Michel Fortin

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and
so it creates inefficient and possibly buggy code.

What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.

If you treat the nested function's context pointer as a pointer to a
struct matching the stack layout, then you can have pure nested
functions -- they have exactly the same semantics as a pure struct
member function.

-- Daniel

[Don]

Post by Daniel Keep

Post by Michel Fortin

Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and
so it creates inefficient and possibly buggy code.

What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.

If you treat the nested function's context pointer as a pointer to a
struct matching the stack layout, then you can have pure nested
functions -- they have exactly the same semantics as a pure struct
member function.
-- Daniel

True, but that would mean that it'd be pretty useless. It's almost
exactly the same as not marking it pure.
pure foo(int x)
{
int y;
pure int bar(int z) { return z*z; }

int a= bar(2);
y++;
int b = bar(2); // has to recalculate bar(2), because y has changed.
}

---
The basic issue is that the situations where marking a nested function
as 'pure' is a good idea, is extremely limited.
Compared to making it an external pure private function, with any
desired immutable members passed as parameters, it has these advantages
and disadvantages.
+ inaccessable to other functions in the same module.
+ can access immutable members in the outer function, without passing
them as parameters.
- slower, since it needs a context pointer as well as a frame pointer.

I think those benefits are pathetic.

[Don]

Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr' is nothrow yet may throw
but I don't understand why. What are the things inside it that can throw an exception?
Bye,
bearophile

Obviously my 2808 patch only solved one part of the problem.
It compiles if you change do_sqr to
void do_sqr() nothrow { y *= y; }
Please add a bug report to Bugzilla.

[tama]

On Mon, 20 Apr 2009 16:09:09 +0900, Walter Bright

Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip

Range is so cool!

Though...
I tried following code:

void main()
{
writeln("Case1");
{
Mt19937 gen = Mt19937(0);
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen = Mt19937(0);
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("?nCase2");
{
Mt19937 gen;
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen;
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
}

Result:

Case1
2357136044 (1)
2546248239 (2)
---
2546248239 (2)
3071714933 (3)

Case2
581869302 (1)
3890346734 (2)
---
581869302 (1)?
3890346734 (2)?

I think 'Case1' is correct, but 'Case2' is wrong.
Mt19937's bug?