Re: order of static constructor execution

[Max Samukha]

On 13.03.2010 2:27, Michel Fortin wrote:

On 2010-03-12 19:10:10 -0500, Max Samukha spam...@d-coding.com said:


If static constructors in templates ran during the initialization of
the module where they are defined, the problem with mixed-in code
could be solved like this:


But templates can take function and types as argument. If the 'static
this' of a template calls something through one of its argument, the
module this function or type resides in needs to be initialized first.

So you can't always call a template's static this at the same time as
the module the template is defined in.



Yes that is the point and purpose.

The advantage is that the programmer is in control of when the static 
constructors in templated code are run - if you want the constructor to 
run in the context of the imported module use a regular template, 
otherwise, mixin.


I'd definitely preferred it over the current semantics. Others may disagree.

Worlds of CTFEs templates

[bearophile]

Currently this program doesn't compile:


template Foo(int x) {
static if (x)
enum int Foo = 1;
else
enum int Foo = 0;
}
int bar() {
if (__ctfe) {
for (int i; i  1; i++)
int r = Foo!(i);
}
return 0;
}
enum int r = bar();
void main() {}


I think it doesn't compile because CTFE functions must be able to run both at 
compile-time and run-time, so it can't call a template that uses a run-time 
variable, even if it's used only by a CTFE function that knows the value at 
compile-time :-)

I think that if(__ctfe){ doesn't improve the situation because that's another 
run-time variable.

But being able to use templates from CTFE functions is very useful, otherwise 
the worlds of CTFE and templates are too much separated (but I think a template 
can call a CTFE function), and the compiler knows that the code inside the 
if(__ctfe){ will never run at run-time.

So can the compiler be modified to allow templates inside the scope of 
if(__ctfe){...} ?

Bye,
bearophile

A possible replacement for pragma(msg,...)

[bearophile]

Here I have reported some bugs/problems of pragma(msg,...):
http://d.puremagic.com/issues/show_bug.cgi?id=3952

At the bottom I have added a small proposal too:

D2 programs have better and better CTFE, so the need for good enough printing 
is growing.

So I suggest to add a special printing function that works in the same way both 
at compile-time in CTFE and at runtime. To keep things simple it can just print 
a string (literal or inside a variable) and it does NOT print a newline.

It can be used in a loop too, in CTFE too, to print many things (so it's 
different from a pragma(msg,...):

string foo(int i) {
foreach (i, 0 .. 10)
ctputs(ToString!(i));
}

Note that it's a true function, so there is no need for {}.

ctputs is just one of the possible names of this function.

Once such function is present, the pragma(msg,...) can probably be removed from 
the language.

Bye,
bearophile

On * Language Design

[Justin Johansson]

I just happened across an essay by Tim Bray 
(http://www.tbray.org/ongoing/misc/Tim)
that he wrote back in 2006 about XML Language Design (I guess he means schema 
design though).

Now why should D people care about this guy's rant about (XML) Language Design?

As I read the essay, the insight that I took away was that you can take out all 
references to XML and replace them with PL (as in programming language) without
loss of generality and most of what he says, imho, is applicable to, and there
are lessons to be learned (or should have been learned in 20/20 hindsight) for
the development of D (and for any aspiring PL for that matter).

Up front he strikes a chord that will be familiar to D people quoting another 
author:

“There are only two hard things in Computer Science: cache invalidation and 
naming things”

And this snippet is a goodie too:

Each and every language-design effort has the potential to blow through its 
deadlines and trail along forever, and offers many chances to fall into the 
bikeshed trap.

The main headings in his essay are:

Expect Semantic Gaps
Manage the Process
The Syntax-vs-Model Wars
Minimalism vs. Completeness
Evolution vs. Stability
Extensibility

If you have the time, this essay by Tim Bray is well-worth a read.  Here's the 
link:

http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design

Enjoy,

Justin Johansson

Re: On * Language Design

[bearophile]

Justin Johansson:
 “There are only two hard things in Computer Science: cache invalidation and 
 naming things”

Wonderful ^_^
Finding good names for things is both hard and important.
Python development process, and the language they have produced, show that 
trying to invent good names is not wasted time. Every single person has quirks. 
So no single person is enough to invent good names. A community of people is 
able to smooth out such quirks and invent names that are good for the higher 
percentage of people. But Python again shows that sometimes in the end the 
final decision of a dictator is necessary (see the x if foo else y syntax), 
both to stop endless discussions, and to keep an uniform design style in the 
language. Most times a dictator is not necessary, and consensus emerges from 
the crowd itself.

Bye,
bearophile

Re: On * Language Design

[Bane]

 If you have the time, this essay by Tim Bray is well-worth a read.  Here's 
 the link:
 
 http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design
 

Interesting point in chapter Evolution vs. Stability. Maybe v2 came to fast, 
before v1 became popular?

Re: Set ops in std.algorithm

[Andrei Alexandrescu]

On 03/10/2010 05:47 PM, bearophile wrote:

This post is mostly for Andrei, but I don't think private emails are
good for this. I suggest to move the set-related functions of
std.algorithm to a different module, because:

1) They are tied to a specific representation of sets (sorted unique
InputRanges), so if I have a BitSet, HashSet, ApproximateBloomSet,
etc, they don't work (they can work with a SearchTreeSet).

2) I think there are too many names/functions in std.algorithm, and
their purpose is a bit too much mixed (and currently algorithm.d
module is 173 kB).

I don't know what can be a good name for such new module,
sorted_input_range_set is (I think) descriptive, but a bit too much
long :-)

Bye, bearophile


That's a good idea, particularly in wake of the fact that std.algorithm 
has grown quite large.


Andrei

Re: Property rewriting; I feel it's important. Is there still time?

[Andrei Alexandrescu]

On 03/10/2010 12:14 PM, bearophile wrote:

Andrei Alexandrescu:

That's a bug worth submitting.


OK:
http://d.puremagic.com/issues/show_bug.cgi?id=3927
(I have not started fixing bugs)

Bye,
bearophile


BTW I noticed that you have recently submitted a great deal of bugs and 
good suggestions to bugzilla. Thanks!


Andrei

Re: Collections in Scala

[Andrei Alexandrescu]

On 03/09/2010 09:13 AM, bearophile wrote:

This post is mostly for Andrei. Fighting Bit Rot with Types (Experience Report: 
Scala Collections) by M. Odersky, A. Moors, found in Lambda the Ultimate blog:
http://lampwww.epfl.ch/~odersky/papers/fsttcs2009.pdf


[snip]


There is enough food for Andrei, the paper is nice.


The paper is interesting, I'm making time to read it this weekend. 
Generally I think there's no need to target posts and suggestions to me; 
that may dissuade others from reading and participating.



Andrei

Re: Set ops in std.algorithm

[Michel Fortin]

On 2010-03-13 12:02:40 -0500, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



On 03/10/2010 05:47 PM, bearophile wrote:

This post is mostly for Andrei, but I don't think private emails are
good for this. I suggest to move the set-related functions of
std.algorithm to a different module, because:

1) They are tied to a specific representation of sets (sorted unique
InputRanges), so if I have a BitSet, HashSet, ApproximateBloomSet,
etc, they don't work (they can work with a SearchTreeSet).

2) I think there are too many names/functions in std.algorithm, and
their purpose is a bit too much mixed (and currently algorithm.d
module is 173 kB).

I don't know what can be a good name for such new module,
sorted_input_range_set is (I think) descriptive, but a bit too much
long :-)

Bye, bearophile


That's a good idea, particularly in wake of the fact that std.algorithm 
has grown quite large.


I think a good module name would be std.sort. You can put the sort 
function as well as functions related to sorted ranges in it.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: On * Language Design

[Don]

Bane wrote:

If you have the time, this essay by Tim Bray is well-worth a read.  Here's the 
link:

http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design



Interesting point in chapter Evolution vs. Stability. Maybe v2 came to fast, 
before v1 became popular?


The naming of D1 vs D2 is a bit misleading. v1 was actually a fairly 
arbitrary snapshot of the development of D, to create a stable branch. 
There was absolutely no pause in language developement.

D2 is completely different. It's a fully planned release.

T.init for static arrays?

[Walter Bright]

Currently, given an array:

   alias T[3] A;
   A a;

the default initializer for A, A.init, is T.init. It is done this way 
for memory efficiency, as:


   a = A.init;

doesn't need to create an array for the rvalue. But it does cause 
generic programming problems, especially with the advent of static 
arrays now being passed by value rather than by ref.


So, I propose changing A.init from being T.init to being [T.init, 
T.init, T.init].


What do you think?

Re: new operator overloading buggy?

[Walter Bright]

Trass3r wrote:

Guess it's better to post this here. Are these some bugs or is there another 
problem?


Can you please do these as complete code snippets?

The reason I ask is because over and over, when I have to guess at the 
obvious rest of the code, the rest of the code turns out to be where 
the problem was.

Re: [OT] zip etiquette

[Chad J]

Lutger wrote:
 Bernard Helyer wrote:
 
 On 12/03/10 18:09, Nick Sabalausky wrote:
 Ellery Newcomerellery-newco...@utulsa.edu  wrote in message
 news:hnc4o3$2lm...@digitalmars.com...

 What I really want is an archive program that automatically makes a
 subfolder by default *but* detects if the top level inside the archive
 contains nothing more than a single folder and intelligently *not* create
 a new folder in that case. But I've yet to see one that does that, and I
 haven't had time to make one.

 The right click 'extract here' under GNOME does *exactly* this.
 
 Same under KDE: Dolphin right click 'extract here, autodetect subfolder' 

Yes, I love this feature.

 
 Perhaps Dolphin will also function under XP, last time I checked KDE was 
 still a bit buggy under windows though. 

Re: T.init for static arrays?

[grauzone]

Walter Bright wrote:

Currently, given an array:

   alias T[3] A;
   A a;

the default initializer for A, A.init, is T.init. It is done this way 
for memory efficiency, as:


   a = A.init;

doesn't need to create an array for the rvalue. But it does cause 
generic programming problems, especially with the advent of static 
arrays now being passed by value rather than by ref.


So, I propose changing A.init from being T.init to being [T.init, 
T.init, T.init].


What do you think?


This assert should never fail:

T x;
assert(x is T.init);

(Right now it fails for floats because of NaN - can we fix this too? 
is should always do byte comparisons.)

C++0x news

[Andrei Alexandrescu]

Executive summary: C++0x will in all likelihood be C++11, export finally 
gets the axe (thank God), exception specifications get deprecated, 
noexcept gets added... well pretty much what D does :o).


Andrei

 Original Message 
Subject:[herb_sutter] Trip report: March 2010 ISO C++ Meeting
Date:   Sat, 13 Mar 2010 19:55:04 +
From:   Herb Sutter hsut...@microsoft.com
Reply-To:   herb_sutter-ow...@yahoogroups.com
To: herb_sut...@yahoogroups.com herb_sut...@yahoogroups.com



Here's the link to the full blog post:
http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ 


http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

I've pasted the post below, but depending on the vagaries of Yahoo
Groups and the email format you selected, quotes and graphics and such
may not format correctly. Enjoy.

Herb

Trip Report: March 2010 ISO C++ Standards
Meetinghttp://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ 


http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

March 13, 2010 by Herb
Sutterhttp://herbsutter.wordpress.com/author/herbsutter/
http://herbsutter.wordpress.com/author/herbsutter/

[Note: I usually post trip reports after the public post-meeting mailing
goes live a few weeks after the meeting, so that I can provide links to
minutes and papers. This time, I wanted to post the report right away to
share the news. If you're interested in the post-meeting papers,
including the official minutes, watch the 2010 papers
pagehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/ which is
where they will appear in a few weeks.]

The ISO C++ committee met in Pittsburgh, PA, USA on March 8-13, 2010,
hosted by the CERT Software Engineering
Institutehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf at
Carnegie Mellon Universityhttp://www.cmu.edu/index.shtml
http://www.cmu.edu/index.shtml. As usual, about 50 experts attended,
and we had eight official national body delegations from Canada,
Finland, France, Netherlands, Spain, Switzerland, United Kingdom, and
United States.

[IMG_0396]The meeting just concluded a few minutes ago (yes, the
meetings run through Saturday afternoon). Here are some highlights of
what happened today, which was another landmark in the progression of
the C++0x standard.

Approved Final Committee Draft (FCD) for C++0x

The biggest news is that this afternoon we voted in the final remaining
feature changes to C++0x, and to much applause then unanimously approved
the text for international ballot as a Final Committee Draft (FCD). FCD
means that, assuming no surprises, we intend to do only bug fixes and
editorial corrections for the next year or so, and then ballot a final
standard. If we can do that, assuming all goes well, C++0x could
officially be published as soon as next year as ISO C++ 2011, and we can
stop with the x-is-hex jokes and just start calling it C++11.

This is a big milestone, and it was achieved thanks to removing a couple
of controversial features last summer and a whole lot of work by the ISO
C++ committee members over the past six months in particular. That work
includes countless hours spent between our full face-to-face meetings at
face-to-face ad-hoc meetings to swat library bugs, teleconferences on
resolving core language questions, and triple-digit person-hours
invested in four teleconferences during December-February purely about C
and C++ compatibility that have greatly helped to identify and attempt
to resolve minor areas of divergence between the C++0x draft standard
and the C1x draft standard (as both are now in progress; C1x is
targeting completion and publication in 2012).

All in all, your committee members have put in an enormous amount of
effort to bring this in, and the draft is in far better shape for this
meeting than anyone could have expected last summer. For comparison, in
my and several others' opinions, it's in better shape than the FCD of
the C++98 standard.

Since we're closing down this round of standardization, we didn't make
many exciting technical changes. Here are two technical highlights of
the meeting that are likely of general interest, finally adopting
changes we've contemplated before.

Removed Export Template

As I reported after the last meeting
(herehttp://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/ 

http://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/ 


and
herehttp://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-c-standards-meeting/ 

http://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-c-standards-meeting/), 


the committee considered the question of whether to deprecate, remove,
or leave in the export template 

Re: T.init for static arrays?

[Andrei Alexandrescu]

On 03/13/2010 02:13 PM, Walter Bright wrote:

Currently, given an array:

alias T[3] A;
A a;

the default initializer for A, A.init, is T.init. It is done this way
for memory efficiency, as:

a = A.init;

doesn't need to create an array for the rvalue. But it does cause
generic programming problems, especially with the advent of static
arrays now being passed by value rather than by ref.

So, I propose changing A.init from being T.init to being [T.init,
T.init, T.init].

What do you think?


The irregularity of .init for arrays has been a huge source of problems. 
I'm very glad you're looking into fixing it.


My understanding is that you propose to transform A.init into a literal 
with as many elements as the length of the array. That has a an issue. 
Currently array literals default to T[], not T[N]. So this would do the 
unexpected:


alias int[3] A;
A a;
auto b =  A.init;
assert(is(typeof(b) == int[]); // pass

I was thinking of rewriting (T[N]).init as:

{ T[N] result; return result; }()

i.e. an rvalue of type T[N]. The lambda should be CTFE-able and does not 
occupy static storage because it creates the temporary on the stack 
(well, for large arrays the compiler would be free to resort to dynamic 
allocation).


Your solution works if you rewrite (T[N]).init as:

(cast(T[N]) [ T.init, T.init, T.init, ... ])


Andrei

Re: T.init for static arrays?

[Philippe Sigaud]

On Sat, Mar 13, 2010 at 21:13, Walter Bright newshou...@digitalmars.comwrote:

 Currently, given an array:

   alias T[3] A;
   A a;

 the default initializer for A, A.init, is T.init. It is done this way for
 memory efficiency, as:

   a = A.init;

 doesn't need to create an array for the rvalue. But it does cause generic
 programming problems, especially with the advent of static arrays now being
 passed by value rather than by ref.

 So, I propose changing A.init from being T.init to being [T.init, T.init,
 T.init].

 What do you think?


That's bug 3826

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

I'm all for A.init being [T.init (n times)], as it indeed broke some of my
code, so thank you for the suggestion Walter.
I was very surprised to see that A.init was T.init.

Andrei:
My understanding is that you propose to transform A.init into a literal
with as many elements
as the length of the array. That has a an issue.
Currently array literals default to T[], not T[N].

Ah, yes.

So this would do the unexpected:

alias int[3] A;
A a;
auto b =  A.init;
assert(is(typeof(b) == int[]); // pass

Currently, this does something as unexpected (at least for me):

assert( !is (typeof(b) == typeof(a))); // b is an int, a is a int[3]

In parallel to what grauzone said, I think this assert should never fail:

T x;
assert(is(typeof(x) == typeof(T.init));


But then I only use small-size static arrays, as parameters in templates. By
small, I mean less than a dozen elements. Other using bigger arrays may
shout at this change...


 Philippe

Re: T.init for static arrays?

[bearophile]

Walter Bright:
 What do you think?

Thank you for considering this problem :-) I have posted a request for this few 
years ago, explaining why it's important for generic code.

In my dlibs1 (for D1) have had to add this Init!() to avoid special-casing many 
of my functions:


ReturnType!({T result; return _recordinit(result);}) Init(T)() {
T result;
return _recordinit(result);
}

struct _Recordinit(T) { T init; }

_Recordinit!(T) _recordinit(T)(T args) {
return _Recordinit!(T)(args);
}


And recently I have added this bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=3826
So I think it's useful to fix this.



 It is done this way for memory efficiency, as:
a = A.init;
 doesn't need to create an array for the rvalue.

It's the first I see an explanation of why it's done this way.

The following examples are written in the page about arrays:
http://www.digitalmars.com/d/2.0/arrays.html

s[] = t;  // the 3 elements of t[3] are copied into s[3]
s[] = t[];// the 3 elements of t[3] are copied into s[3]
s[] = 3;  // same as s[0] = 3, s[1] = 3, s[2] = 3
p[0..2] = 3;  // same as p[0] = 3, p[1] = 3


Following Python Zen, I don't like to have two different syntaxes to do the 
same thing, so this can become a syntax error:

int[3] a, b;
a[] = a;


So you must write:

int[3] a, b;
a[] = a[];


This is also allowed:

int[3] a;
int i;
a[] = i;


This has to be a syntax error:

int[3] a;
int i;
a[] = i[];


So once array.init is [init, init, ...] this will be allowed (but can't the 
compiler recognize and optimize this situation in many cases?):

int[3] a;
a[] = a.init[];


To save memory the programmer can use:

int[3] a;
a[] = a[0].init;



Regarding the assert(float.init is NaN) and the is meant as binary compare I 
don't mind it. Making the language more orthogonal and removing special cases 
reduces language complexity in programmes heads, books, and makes generic code 
simpler.

Bye and thank you,
bearophile

Re: T.init for static arrays?

[bearophile]

Following Python Zen, I don't like to have two different syntaxes to do the 
same thing, [...]

That was not clear enough, second try:


a[] = b[];  static  dynamic
static  OK1 OK1
dynamic OK1 OK1

a = b[];static  dynamic
static  Err Err
dynamic Err Err

a[] = b;static  dynamic
static  Err Err
dynamic Err Err

a = b;  static  dynamic
static  Err2Err
dynamic Err OK2

int i; a=i; static  dynamic
Err Err

int i;
a[] = i;static  dynamic
OK3 OK3

Key:
  Err =  Syntax error
  OK1 =  Copies all items from an array to the oter.
  OK2 =  Copies just the stuct of the dynamic array, array body not copied.
  OK3 =  Copies the value to all the items of the array.
  Err2 = Syntax error, becase there is no reference to copy, better keep 
language tidy.


You can see I have disallowed this too:
int a, b;
a = b;

This breaks generic code, but Andrei said that it's bad when the same syntax 
can be O(1) (because the same done on dynamic arrays is a O(1)) or O(n). And 
the semantics is too much different.

You are free to disagree. The good thing is that now I have those matrices of 
all cases, so it's easy to see and design :-)
The final version of those matrices can be added to this page:
http://www.digitalmars.com/d/2.0/arrays.html

Bye,
bearophile

Re: On * Language Design

[Bane]

  Interesting point in chapter Evolution vs. Stability. Maybe v2 came to 
  fast, before v1 became popular?
 
 The naming of D1 vs D2 is a bit misleading. v1 was actually a fairly 
 arbitrary snapshot of the development of D, to create a stable branch. 
 There was absolutely no pause in language developement.
 D2 is completely different. It's a fully planned release.

From the article:

...Having said that, the advantages to stopping with 1.0 are huge. Here’s why: 
one of the main success factors for a new XML language is how much software 
there is out there that does useful things with it. (See my proposed 
restatement of Metcalfe’s law over in the companion piece.) And software 
developers love a stable target above all things. If you publish 1.0 of your 
language and are fortunate enough to get some uptake in the developer community 
so some useful tools are shipping, bear in mind that if you then release 2.0, 
you’ve quite likely broken all those tools. You can maybe do this once before 
the developers are going to start seeing you as part of the problem rather than 
as part of the solution. They might just give up on you, or they might decide 
to go on maintaining their 1.0-compatible releases and simply ignore your 2.0, 
which will then likely go un-used. This is more or less exactly what happened 
to XML 1.1 which, despite having my name on the cover, I though!
 t was a bad idea and fought every step of the way...

Just found some truth in all said above. Luckuly, difference between D1 and D2 
isn't that great (I hope)

Re: C++0x news

[Walter Bright]

Andrei Alexandrescu wrote:
Executive summary: C++0x will in all likelihood be C++11, export finally 
gets the axe (thank God),


Yay!

exception specifications get deprecated, 


Yay!


noexcept gets added... well pretty much what D does :o).


I predict that C++ will adopt a lot more of D stuff.

Re: On * Language Design

[bearophile]

Bane:
 Just found some truth in all said above. Luckuly, difference between D1 and 
 D2 isn't that great (I hope)

I think Walter  Co. have taken the right decisions about versions and 
releases, so I am happy about how he has managed the versions.
The only thing that I don't fully like is the release date for the D2, I think 
it's a little too much early, because I think few more tiny breaking changes 
can be useful for D2. (But I know Andrei's situation). Thankfully Andrei has 
probably avoided to put part of the dark corner cases of D2 in his book, so 
they can be fixed still :-)

Bye,
bearophile

Re: new operator overloading buggy?

[Trass3r]

Can you please do these as complete code snippets?

The reason I ask is because over and over, when I have to guess at the  
obvious rest of the code, the rest of the code turns out to be where  
the problem was.


I understand. Thanks for your answer.

2nd issue is now: http://d.puremagic.com/issues/show_bug.cgi?id=3935

3rd issue has become: http://d.puremagic.com/issues/show_bug.cgi?id=3941

need to have a look at the first one when I get some time. I spent much  
too much time in the dmd frontend yesterday ^^

shouldn't override be obligatory?

[Trass3r]

so you don't accidentally override a base class method without knowing it.

Re: shouldn't override be obligatory?

[bearophile]

Trass3r:
 so you don't accidentally override a base class method without knowing it.

I'm trying to help D become tidier, I have added this days ago:
http://d.puremagic.com/issues/show_bug.cgi?id=3836

Bye,
bearophile

Re: future for async calling?

[Robert Jacques]

On Sat, 13 Mar 2010 17:31:03 -0500, Nick Sabalausky a...@a.a wrote:
I just came across this interesting article about a generic type  
future,
and was wondering is something like it was planned for Phobos (or Tango  
for
that matter), or was already in (I haven't been paying a lot of  
attention to

D concurrency), or just any thoughts about it in relation to D:

Beginning of obnoxiously multi-paged article:
http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=222301165pgno=1

Direct link to the page with the real meat:
http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=222301165pgno=3




Futures aren't planned for Phobos yet, because 1) they're hard to do  
safely and 2) message passing comes first. That said, there is already  
several libraries on dsource that have futures. I'd recommend dsimcha's  
parallelFuture library (http://cis.jhu.edu/~dsimcha/parallelFuture.html,  
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d).  
BTW the term 'future' has unfortunately been saddled with some poor  
implementations in the past and; this style of programming is often  
referred to as task programming.

Re: shouldn't override be obligatory?

[Nick Sabalausky]

Trass3r u...@known.com wrote in message 
news:op.u9i1zxqa3nc...@hoenir.fem.tu-ilmenau.de...
 so you don't accidentally override a base class method without knowing it.

I read about override when I first got into D way back before D1.0 and 
thought it sounded great. Then I promptly forgot about it since the compiler 
never complained, and I haven't even thought to use it since. I suspect I'm 
not the only one that's happened to.

Therefore, if there's potential benefit to be gained from override (and I 
believe that there is), then I don't think we're actually *getting* much of 
that benefit as things currently are. Although, as far as whether or not 
that benefit is worth the bother of it being required, well, I haven't given 
any thought to that in a long time, so I'm really not sure either way, ATM. 

Re: C++0x news

[bearophile]

Nick Sabalausky:
 but judging by these reactions it sounds like there was some sort of 
 critical flaw with them?

It seems that implementing a whole Java VM requires less time than to implement 
just that not very useful feature :-)


 I predict that it still won't be nearly enough to make C++ nice to deal with 
 compared to D ;)

The problem is that even if they can add most of the D things, they can't 
remove other C++ things. And it's already the biggest ball of mud among 
programming languages.

Bye,
bearophile

Re: shouldn't override be obligatory?

[Nick Sabalausky]

Nick Sabalausky a...@a.a wrote in message 
news:hnh4kl$1iq...@digitalmars.com...
 Trass3r u...@known.com wrote in message 
 news:op.u9i1zxqa3nc...@hoenir.fem.tu-ilmenau.de...
 so you don't accidentally override a base class method without knowing 
 it.

 I read about override when I first got into D way back before D1.0 and 
 thought it sounded great. Then I promptly forgot about it since the 
 compiler never complained, and I haven't even thought to use it since. I 
 suspect I'm not the only one that's happened to.

 Therefore, if there's potential benefit to be gained from override (and 
 I believe that there is), then I don't think we're actually *getting* much 
 of that benefit as things currently are. Although, as far as whether or 
 not that benefit is worth the bother of it being required, well, I haven't 
 given any thought to that in a long time, so I'm really not sure either 
 way, ATM.

Although, I will say that Haxe requires override, and I've been writing a 
lot of Haxe lately, and I've never found it annoying there (other parts of 
Haxe I've found annoying...but not that ;) ). 

Re: C++0x news

[Nick Sabalausky]

bearophile bearophileh...@lycos.com wrote in message 
news:hnh4o4$1iu...@digitalmars.com...
 Nick Sabalausky:

 I predict that it still won't be nearly enough to make C++ nice to deal 
 with
 compared to D ;)

 The problem is that even if they can add most of the D things, they can't 
 remove other C++ things. And it's already the biggest ball of mud among 
 programming languages.


Exactly! 

Re: shouldn't override be obligatory?

[Michel Fortin]

On 2010-03-13 17:27:23 -0500, Trass3r u...@known.com said:


so you don't accidentally override a base class method without knowing it.


It's my opinion that it should.

(bugzilla 3836)++


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: new operator overloading buggy?

[Walter Bright]

Trass3r wrote:

2nd issue is now: http://d.puremagic.com/issues/show_bug.cgi?id=3935

3rd issue has become: http://d.puremagic.com/issues/show_bug.cgi?id=3941


Perfect. Thanks!

Re: shouldn't override be obligatory?

[Andrei Alexandrescu]

On 03/13/2010 04:27 PM, Trass3r wrote:

so you don't accidentally override a base class method without knowing it.


It is in TDPL so it is in the language :o).

Andrei

[OT] Business idea: make a case that makes the iPhone look like a Windows phone

[Andrei Alexandrescu]

http://online.wsj.com/article/SB10001424052748703455804575057651922457356.html#articleTabs%3Darticle

Andrei

Re: C++0x news

[BCS]

Hello Walter,


I predict that C++ will adopt a lot more of D stuff.



Imitation is the sincerest form of flattery?

--
... IXOYE

Re: C++0x news

[Jonathan M Davis]

Nick Sabalausky wrote:

 Walter Bright newshou...@digitalmars.com wrote in message
 news:hnh30m$1fv...@digitalmars.com...
 Andrei Alexandrescu wrote:
 Executive summary: C++0x will in all likelihood be C++11, export finally
 gets the axe (thank God),

 Yay!

 
 I had to look up what export templates were. It *seemed* like a good
 thing, but judging by these reactions it sounds like there was some sort
 of critical flaw with them?
 

Herb Sutter did a great article on it:

http://www.drdobbs.com/cpp/184401563
http://www.drdobbs.com/cpp/184401584

Basically what it comes down to is that they don't really work and that 
trying to make them work breaks things. On top of that, they're really hard 
to implement, and I believe that only one group has done it (and as 
Bearophile pointed out, it took them long to implement template exports than 
it did for them to implement the entire java specification).

- Jonathan M Davis

Re: [OT] Business idea: make a case that makes the iPhone look like a Windows phone

[Bill Baxter]

On Sat, Mar 13, 2010 at 4:04 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
 http://online.wsj.com/article/SB10001424052748703455804575057651922457356.html#articleTabs%3Darticle

Hopefully Win Mobile 7 will offer some decent competition at last.
Cautiously optimistic here.

--bb

Re: what's the difference between ref and inout in D2?

[Trass3r]

The compiler prints an error because y is seen as const. So a better  
question (I don't know the answer) is: what's the purpose of in if now  
function arguments can be const?




Had another look.
If no storage class is specified, the parameter becomes a mutable copy of  
its argument

The in storage class is equivalent to const scope.

But what is scope in this context?

aa literals

[Ellery Newcomer]

anyone know of a good (or any) syntax for an empty aa

impetus:

auto aa = reduce!(g)(emptyaa, lst);

Re: aa literals

[bearophile]

Ellery Newcomer:

 anyone know of a good (or any) syntax for an empty aa

Unfortunately null suffices where the function that receives knows the type 
of the AA it will receive. But I don't like this, a more typed style can be 
less bug prone.

So you can give a type to null:
cast(int[string])null

I have created a bit shorter template:
AA!(string, int)

But it doesn't gain much.

Something similar can be used for dynamic arrays:
cast(int[])null
With dynamic arrays you can also use (that I don't like) null and even the 
special []

Bye,
bearophile

Re: aa literals

[Philippe Sigaud]

On Sat, Mar 13, 2010 at 20:17, Ellery Newcomer
ellery-newco...@utulsa.eduwrote:

 anyone know of a good (or any) syntax for an empty aa

 impetus:

 auto aa = reduce!(g)(emptyaa, lst);


To associate a list of key/value pairs into one AA?

I use .init, but AA in general have become buggy for the past few releases.

auto aa = reduce!g((V[K]).init, lst); // this used to work, I think

But, as I said, it has become quite buggy recently:

auto aa = (int[string]).init; // empty AA?
aa[abc] = 3; // error, no operator [] overload for
AssociativeArray!(string, int). I mean, come on.


Philippe

Re: aa literals

[bearophile]

Ellery Newcomer:
 anyone know of a good (or any) syntax for an empty aa
 impetus:
 auto aa = reduce!(g)(emptyaa, lst);

Sorry, I have probably not understood your question.

Bye,
bearophile

Re: aa literals

[Ellery Newcomer]

On 03/13/2010 07:20 PM, bearophile wrote:

Ellery Newcomer:

anyone know of a good (or any) syntax for an empty aa
impetus:
auto aa = reduce!(g)(emptyaa, lst);


Sorry, I have probably not understood your question.

Bye,
bearophile


No, you hit it on the head. Here's the kind of thing I was after:

auto g = reduce!(a[b]=1,a)(cast(int[int]) null, [1,2,3,4]);

Works fine. The one-liner probably isn't worth it, but I think it's 
pretty funny. What does this do to Walter's arguments concerning nonnull?

[Issue 3946] New: schwartzSort - SwapStrategy always unstable

[d-bugmail]

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

   Summary: schwartzSort - SwapStrategy always unstable
   Product: D
   Version: 2.041
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: 9...@rambler.ru


--- Comment #0 from Ilya Yaroshenko 9...@rambler.ru 2010-03-13 00:41:34 PST 
---
In the last line sort calling without ss (SwapStrategy) - it is looks like
always unstable:

module std.algorithm;

void schwartzSort(alias transform, alias less = a  b,
SwapStrategy ss = SwapStrategy.unstable, Range)(Range r)
if (isRandomAccessRange!(Range)  hasLength!(Range))
{
alias typeof(transform(r.front)) XformType;
auto xform = new XformType[r.length];
foreach (i, e; r)
{
xform[i] = transform(e);
}
auto z = zip(xform, r);
alias typeof(z.front()) ProxyType;
bool myLess(ProxyType a, ProxyType b)
{
return binaryFun!(less)(a.at!(0), b.at!(0));
}
sort!(myLess)(z);   /// -
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3947] New: Implicit and explicit casting of floating point to bool produces different results

[d-bugmail]

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

   Summary: Implicit and explicit casting of floating point to
bool produces different results
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com


--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-13 01:50:09 
PST ---
Created an attachment (id=587)
test case with comments

I've observed that these are the rules for explicitly casting floating point
numbers to bool:

- finite real numbers  -1 and  1 are false
- all other real number values are true (including NaN)
- all imaginary numbers are false, since their real part is 0
- complex numbers as bool are the same as their real part as bool

I've noticed that the rules for implicitly casting floating point numbers to
bool, as in the expression (a  b), is different in several ways:

- real 0 and -0 are false
- all other finite real numbers  -1 and  1 are *true*
- all other real number values are true (including NaN)
- imaginary 0 and -0 are false
- finite imaginary numbers  -1 and  1 are *true*
- all other real number values are *true* (including NaN)
- complex numbers as bool are the same as the real *or* imaginary part as bool
under this new scheme. If either evaluates to true, then the complex is true.

There should be a single set of rules used for both cases.
As it is, I don't know which part of each set is right.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3694] Template this parameters don't work with operator overloads

[d-bugmail]

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


Tomasz Sowiński tomeks...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Tomasz Sowiński tomeks...@gmail.com 2010-03-13 03:53:06 
PST ---
(In reply to comment #2)
 Bug appears to be fixed in DMD 2.041. Both test cases compile fine now.

Also works here. I'm marking as fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2656] Require 0o format for octal literals

[d-bugmail]

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



--- Comment #9 from bearophile_h...@eml.cc 2010-03-13 04:22:57 PST ---
I agree that the 0o prefix is not very readable.

What about using Octal!50 instead (no leading zero. No string)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3943] in function argument is redundant

[d-bugmail]

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



--- Comment #2 from bearophile_h...@eml.cc 2010-03-13 04:33:05 PST ---
My opinions on the topic:
- As a Python user I have seen the usefulness of that part of its Zen. It
speeds up coding, speeds up code reading, makes code more uniform among
different programmers, etc.
- When Andrei's book is out, people will learn the D2 language. I like D1 but
it will probably not last many years. I think some years from now D1 will be
unused. Keeping in D2 a redundancy and baggage for a language that will not
last is bad.

So if you don't want to remove that in now, to help in the transitory period
of code that works in D1 and D2, it can be kept, deprecated, _plus_ it has to
always raise an informative deprecation warning, it must be noisy, otherwise
new D2 programmers will use it and it will never be possible to remove it from
the language. And then it can be removed in one or two years from now.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3949] New: Wrong sized array plus pragma crashes compiler

[d-bugmail]

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

   Summary: Wrong sized array plus pragma crashes compiler
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 04:48:43 PST ---
This crashes the compiler:

enum int[1] a = [0, 1];
pragma(msg, a);


The compiler prints:
Assertion failure: 'j  edim' on line 445 in file 'init.c'

See related bug 3948 too. I don't know if the cause is the same.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3950] New: Wrong error message in recursive template call with no !

[d-bugmail]

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

   Summary: Wrong error message in recursive template call with no
!
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 04:51:48 PST ---
This is wrong D2 code (there is a ToString(x % 10) with no bang):


template ToString(ulong x) {
static if (x  10)
enum string ToString =  ~ cast(char)(x + '0');
else
enum string ToString = ToString!(x / 10) ~
   ToString(x % 10); // missing ! here
}
pragma(msg, ToString!(10));
void main() {}


The compiler gives a wrong error message:
test.d(8): Error: template instance bug3.ToString!(10) recursive expansion

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3951] New: [CTFE] With a fixed-size array

[d-bugmail]

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

   Summary: [CTFE] With a fixed-size array
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 04:55:46 PST ---
I can't invent a good name for this bug.
This looks valid CTFE code, but it doesn't compile:


int foo1(int n)(int[n] array) {
foreach (el; array) {}
return 0;
}
int foo2(int n)(int[n] array) {
for (int i; i  n; i++) {
int el = array[i];
}
return 0;
}
int spam() {
int[1] array;
enum int i1 = foo1(array);
enum int i2 = foo2(array);
return 0;
}
enum int r = spam();
void main() {}



Errors produced:
test.d(12): Error: cannot cast int to int[]
test.d(12): Error: cannot cast int to int[]
test.d(12): Error: cannot cast int to int[]
test.d(13): Error: cannot evaluate foo1(array) at compile time
test.d(13): Error: cannot evaluate foo1(array) at compile time

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3952] New: pragma(msg,...) has bugs + alternative idea

[d-bugmail]

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

   Summary: pragma(msg,...) has bugs + alternative idea
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 05:11:28 PST ---
The D2 docs state about pragma(msg, ...):
Prints a message while compiling, the AssignExpressions must be string
literals:
pragma(msg, compiling...);

I think that means it must accept string literals only, and produce a syntax
error in all the other cases. In practice if you look at the following program
the pragma(msg, foo0()); prints the this is a test string. This is useful,
but in many other cases this doesn't work or works in strange ways:


string foo0() {
return this is a test;
}
string foo1() {
return ;
}
string foo2() {
string result;
return result;
}
string foo3() {
return [];
}
pragma(msg, foo0());
pragma(msg, foo1());
pragma(msg, foo2());
pragma(msg, foo3());
string hello = red;
pragma(msg, hello);
pragma(msg, 12);
void main() {}



The compile-timeoutput of that program is:
this is a test

null
[]
hello
12


So I think pragma(msg,...) needs some debugging.

-

This program doesn't compile:


enum int x = 10;
static if (x)
pragma(msg, true);
else
pragma(msg, false);
void main() {}



It prints the error:
test.d(4): Declaration expected, not 'else'

I can understand the cause of that error, but to improve the usefulness of the
pragma and avoid errors like that one I think the compiler can rewrite the
pragma(msg, ...) as:

{pragma(msg, ...);}

-

To increase the usefulness of the pragma(msg, ...) I suggest to not let it
print a newline after the string.

-

D2 programs have a better and better CTFE, so the need for good enough printing
is growing.

So I suggest to add a simple printing function that works in the same way both
at compile-time in CTFE and at runtime. To keep things simple it can just print
a string (literal or inside a variable) and it does NOT print a newline.

It can be used in a loop too, in CTFE too, to print many things (so it's
different from a pragma(msg,...):

string foo(int i) {
foreach (i, 0 .. 10)
ctputs(ToString!(i));
}

Note that it's a true function, so there is no need for {}.

ctputs is just one of the possible names of this function.

Once such function is present, the pragma(msg,...) can probably be removed from
the language.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3946] schwartzSort - SwapStrategy always unstable

[d-bugmail]

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


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||and...@metalanguage.com


--- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-03-13 
07:00:46 PST ---
Thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2656] Require 0o format for octal literals

[d-bugmail]

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



--- Comment #10 from Andrei Alexandrescu and...@metalanguage.com 2010-03-13 
07:01:53 PST ---
(In reply to comment #9)
 I agree that the 0o prefix is not very readable.
 
 What about using Octal!50 instead (no leading zero. No string)?

Unfortunately that would preclude expressing large numbers in octal.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1730] Bogus error message calling a non-const struct method on a const struct reference

[d-bugmail]

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


Michal Spadlinski gim...@gmail.com changed:

   What|Removed |Added

 CC||gim...@gmail.com


--- Comment #4 from Michal Spadlinski gim...@gmail.com 2010-03-13 07:25:52 
PST ---
I has similar problem with:

struct Foo {
bool boo() {
return false;
}

int foo () const {
assert (boo);
return 66;
}
}

this message is totally misleading

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3940] altsep not found

[d-bugmail]

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



--- Comment #2 from Ellery Newcomer ellery-newco...@utulsa.edu 2010-03-13 
08:12:27 PST ---
(In reply to comment #1)
 There isn't an alternate separator on Linux, making a dummy one doesn't make
 much sense.

Then why does there pretend to be one? It's defined as

static if(Posix){
  immutable char[0] altsep;
}

Makes writing portable code more obnoxious. Perhaps an array of separators
could be defined, e.g.

static if(Windows){
  immutable string[] seps = [sep, altsep];
}
static if(Posix){
  immutable string[] seps = [sep]
}

would express the fact a bit more cleanly

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3954] New: DeclDef rule is missing TemplateMixinDeclaration

[d-bugmail]

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

   Summary: DeclDef rule is missing TemplateMixinDeclaration
   Product: D
   Version: 2.041
  Platform: All
   URL: http://digitalmars.com/d/2.0/module.html
OS/Version: All
Status: NEW
  Keywords: spec
  Severity: normal
  Priority: P2
 Component: www.digitalmars.com
AssignedTo: nob...@puremagic.com
ReportedBy: jlqu...@optonline.net


--- Comment #0 from Jerry Quinn jlqu...@optonline.net 2010-03-13 08:28:40 PST 
---
TemplateMixinDeclaration was added recently, but was not added to the DeclDef
rule that would call it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3955] New: Very poor error message: accidentally assigning to string literal in template

[d-bugmail]

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

   Summary: Very poor error message: accidentally assigning to
string literal in template
   Product: D
   Version: 1.056
  Platform: All
OS/Version: All
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: matti.niemenmaa+dbugzi...@iki.fi


--- Comment #0 from Matti Niemenmaa matti.niemenmaa+dbugzi...@iki.fi 
2010-03-13 08:34:35 PST ---
For the following code:


template T(char[] s) {
static if (s[0] = 'f') // error here; line 2
const T = ;
else
const T =  ~ T!(s);
}

const char[] A = T!(foo); // line 8
const char[] B =  ~ A;


DMD 1.056 emits:

$ dmd -c arst.d
arst.d(8): Error: cannot implicitly convert expression (__error ~ __error) of
type int to char[]

Which is about as obtuse as possible:

- __error looks like something that should only show up when debugging the
compiler. It's certainly not to be found anywhere in the source.
- There is no ~ on line 8: the message points only to the use of T, not the
actual problem which is within T.
- DMD's usual habit of using int when it hits any kind of error.

Removing the apparently unrelated constant B from line 9, we get the following
message that actually indicates the problem. This is what I'd expect to get
regardless of B:

$ dmd -c arst.d
arst.d(2): Error: string literals are immutable
arst.d(2): Error: expression 'f' = 'f' is not constant or does not evaluate to
a bool

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3956] New: linker removes underscore from all exported symbols of a module but the first

[d-bugmail]

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

   Summary: linker removes underscore from all exported symbols of
a module but the first
   Product: D
   Version: unspecified
  Platform: Other
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de


--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2010-03-13 09:18:09 
PST ---
this test program:

module testexport;

export void foo1() {}
export void foo2() {}
export void foo3() {}

void main() {}

compiles, but exports in the resulting executable (not a DLL here for
simplicity) are wrong.

dumpbin /exports testexport.exe
[...]
ordinal hint RVA  name

  10 3014 D10testexport4foo2FZv
  21 3018 D10testexport4foo3FZv
  32 3010 _D10testexport4foo1FZv
[...]

The object file seems ok, here's a snippet from obj2asms' output:

extrn_D10testexport4foo1FZv
;expdef expflag=x00, export '_D10testexport4foo1FZv', internal '',
ordinal=x0
extrn_D10testexport4foo2FZv
;expdef expflag=x00, export '_D10testexport4foo2FZv', internal '',
ordinal=x0
extrn_D10testexport4foo3FZv
;expdef expflag=x00, export '_D10testexport4foo3FZv', internal '',
ordinal=x0
[...]
public_D10testexport12__ModuleInfoZ
_D10testexport4foo1FZvCOMDAT flags=x0 attr=x0 align=x0 
_D10testexport4foo2FZvCOMDAT flags=x0 attr=x0 align=x0 
_D10testexport4foo3FZvCOMDAT flags=x0 attr=x0 align=x0 
__DmainCOMDAT flags=x0 attr=x0 align=x0

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2656] Remove octal literals

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

Summary|Require 0o format for octal |Remove octal literals
   |literals|


--- Comment #11 from Don clugd...@yahoo.com.au 2010-03-13 12:19:22 PST ---
(In reply to comment #10)
 (In reply to comment #9)
  I agree that the 0o prefix is not very readable.
  
  What about using Octal!50 instead (no leading zero. No string)?
 
 Unfortunately that would preclude expressing large numbers in octal.

I don't think it matters what we do. The point is, octal literals are
*extremely* obscure, and don't need to be in the core language, especially with
such a subtle, bug-prone syntax.
If we agree to remove them from the core language, decision about the syntax
should be treated the same as any other standard library syntax issue. It's not
urgent to decide library naming issues right now.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2656] Remove octal literals

[d-bugmail]

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



--- Comment #12 from Andrei Alexandrescu and...@metalanguage.com 2010-03-13 
13:02:23 PST ---
Well put, Don!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 122] DDoc newline behaviour produces suboptimal results

[d-bugmail]

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



--- Comment #2 from Don clugd...@yahoo.com.au 2010-03-13 13:05:06 PST ---
I've worked out what this is. Trailing newlines don't get stripped from the
Description section. Yes, action on an ancient bug!

Here's a test case:

/**
foo1

this has one BR*/
void foo1();
/**
foo2

this also has one BR
*/
void foo2();

/**
foo3

this still just has one BR

*/
void foo3();

/**
foo4

but this has two BRs!!


*/
void foo4();

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3958] New: mixin(non-static method) crashes compiler

[d-bugmail]

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

   Summary: mixin(non-static method) crashes compiler
   Product: D
   Version: 1.057
  Platform: All
   URL: http://thecybershadow.net/
OS/Version: All
Status: NEW
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com


--- Comment #0 from Vladimir thecybersha...@gmail.com 2010-03-13 14:53:46 PST 
---
struct S
{
string g() { return ; }
void f() { mixin(g()); }
}


Making g() static stops DMD from crashing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3958] mixin(non-static method) crashes compiler

[d-bugmail]

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


nfx...@gmail.com changed:

   What|Removed |Added

 CC||nfx...@gmail.com


--- Comment #1 from nfx...@gmail.com 2010-03-13 14:58:02 PST ---
There's another problem. This fails to compile:

struct S
{
static string g() { return null; }
void f() { mixin(g()); } //line 4
}

z.d(4): Error: argument to mixin must be a string, not (null)

(Tested with dmd v2.041.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3948] Array literal assign to array of different length

[d-bugmail]

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



--- Comment #1 from bearophile_h...@eml.cc 2010-03-13 15:04:09 PST ---
See also related bug 3949 .


Another case, this compiles with no errors, but it's bug-prone:

const real x = 1.2;
real[4][4] M2 = [[0, 0, 1, x], [0, 0, 0, 1]];
void main() {}



This doesn't compile:

const real x = 1.2;
real[2][4] M2 = [[0, 0, 1, x], [0, 0, 0, 1]];
void main() {}


But the error message is bad and can be improved:
test.d(3): Error: cannot implicitly convert expression ([0,0,0,1]) of type
int[] to real[2u]



This code:

real x = 1.2;
real[4][4] M2 = [[1, 0, 0, x],
 [0, 1, 0, x],
 [0, 0, 1, x],
 [0, 0, 0, 1]];
void main() {}


Produces the following errors (I don't know if this is correct):

bug1.d(5): Error: non-constant expression x
bug1.d(5): Error: non-constant expression x
bug1.d(5): Error: non-constant expression x

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3959] New: can't mixin result of templated static struct method

[d-bugmail]

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

   Summary: can't mixin result of templated static struct method
   Product: D
   Version: 1.057
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com


--- Comment #0 from Vladimir thecybersha...@gmail.com 2010-03-13 15:20:17 PST 
---
struct S
{
static string g()() { return ; }
}

void f()
{
mixin(S.g!()());
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3960] New: Unused variable warning

[d-bugmail]

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

   Summary: Unused variable warning
   Product: D
   Version: 2.041
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 16:48:40 PST ---
This is C program:

#include stdio.h
#include stdlib.h
int main(int argc, char** argv) {
int x, y;
x = (argc  1) ? atoi(argv[1]) : 10;
printf(%d\n, x);
return 0;
}


Compiled with gcc v.4.4.1 with:
gcc -Wall foo.c -o foo

The compiler prints:
foo.c: In function 'main':
foo.c:4: warning: unused variable 'y'


The Intel C/C++ compiler gives a similar error (this is a mockup, but it's
equal or very close to the real one):
foo.c(4): warning #177: variable y was declared but never referenced
int x, y;
   ^
---

This is C# code:

using System;
public class Foo {
public static void Main() {
int x, y;
x = int.Parse(Console.ReadLine());
Console.WriteLine(x);
}
}


With default settings the C# compiler prints:
prog.cs(4,16): warning CS0168: The variable `y' is declared but never used
Compilation succeeded - 1 warning(s)


This explains the warning CS0168:
http://msdn.microsoft.com/en-us/library/tf85t6e4.aspx

---

In Java all the most important editors/IDEs detect unused local variables:
JDeveloper, Eclipse, JEdit, JBuilder, BlueJ, CodeGuide, NetBeans/Sun Java
Studio Enterprise/Creator, etc.


If the most important compilers/IDEs of the most important and used languages
(C/C++, C#, Java) give warnings for unused variables, then it can be an useful
warning.

By itself an unused variable is not an error, but its presence is often caused
due to oversight (either you declared a variable you didn't need or you
refactored and a variable that was once needed now is no long needed). While
coding in C the GCC compiler has avoided me 2 possible bugs thanks to that
unused variable warning, because I was forgetting some part of the code.

So I believe this warning can be useful in D too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3961] New: [ICE] with to!

[d-bugmail]

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

   Summary: [ICE] with to!
   Product: D
   Version: 2.041
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-03-13 17:16:12 PST ---
This code crashes dmd:


import std.conv: to;
struct Int { int x; }
void main() {
Int i = to!Int(1);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---