Re: So why doesn't popFront return an element?

[Jonathan M Davis]

> Oh, I thought the compiler could optimize calls to popFront if I'm not
> assigning its value.
> 
> Doesn't a technique exist where if a function is called and I'm not
> assigning its result anywhere it should simply exit the function
> without returning anything? It seems like a valuable compiler
> optimization, if that is even possible.

That would depend on the type. For anything other than structs, if the 
function is inlined, it should be able to do that (if it's not inlined, it 
can't, because the returning is done inside of the function call). For 
structs, it can probably do that if there's no postblit constructor and none 
of its member variables have postblit constructors (or have member variables 
of their own which have postblit constructors, etc.). If there's a postblit 
constructor, however, it would have to be pure, otherwise it could have side 
effects, and not doing the return could then alter the behavior of the 
program. However, if it's pure, it probably can. I don't know what the 
compiler does exactly.

Regardless, in the general case, the return value can't be optimized out, 
because that's done in the function call, not at the call site. Inlined 
functions should be able to get the optimization as long as it doesn't change 
the behavior of the program to do so, which could require that the postblit 
constructor is pure if a struct is being returned, and if you're returning an 
expression, then that expression is still going to have to be evaluated unless 
the compiler can determine that it has no side effects, which again, could 
require any functions involved to be pure.

So, don't bet on such an optimization happening. dmd might manage it in some 
cases, but in the most obvious cases, the cost of the return is pretty low 
anyway (since it's either a primitive type or a reference).

- Jonathan M Davis

Re: So why doesn't popFront return an element?

[bearophile]

Andrej Mitrovic:

> Oh, I thought the compiler could optimize calls to popFront if I'm not
> assigning its value.
> 
> Doesn't a technique exist where if a function is called and I'm not
> assigning its result anywhere it should simply exit the function
> without returning anything? It seems like a valuable compiler
> optimization, if that is even possible.

The function may have different calling points, including having its pointer 
taken and passed around. So you generally need the full compiled function, that 
generates the output too.

If the compiler is able to perform some kind of "whole program optimization" 
(today both GCC and LLVM are able to do some of it), and the compiler is able 
to infer that the result of popFront is never used in the whole program, then 
it might be able to remove the dead code that generates the output.

If the compiler inlines popFront at a call point, and in this call point the 
result is not used, all compilers are usually able to remove the useless 
computations of the result.

Some time ago I have proposed a __used_result boolean flag, usable inside 
functions. If inside a function you use this value (inside a "static if"), the 
function becomes a template, and it generally gets compiled two times in the 
final binary. If at a calling point the result of the function doesn't get 
used, the compiler calls the template instantiation where __used_result is 
false, so with the static if you are able to avoid computing the result.

So this program:

int count = 0;

int foo(int x) {
count++;
static if (__used_result) {
int result = x * x;
return result;
}
}

void main() {
foo(10);
int y = foo(20);
}


Gets rewritten by the compiler to something like:

int count = 0;

auto foo(bool use_return)(int x) {
count++;
static if (use_return) {
int result = x * x;
return result;
}
}

void main() {
foo!false(10);
int y = foo!true(20);
}


That produces:

_D4test11__T3fooVb0Z3fooFiZvcomdat
pushEAX
mov ECX,FS:__tls_array
mov EDX,[ECX]
inc dword ptr _D4test5counti[EDX]
pop EAX
ret

_D4test11__T3fooVb1Z3fooFiZicomdat
pushEAX
mov ECX,FS:__tls_array
mov EDX,[ECX]
inc dword ptr _D4test5counti[EDX]
imulEAX,EAX
pop ECX
ret

Bye,
bearophile

Re: So why doesn't popFront return an element?

[Andrej Mitrovic]

Oh, I thought the compiler could optimize calls to popFront if I'm not
assigning its value.

Doesn't a technique exist where if a function is called and I'm not
assigning its result anywhere it should simply exit the function
without returning anything? It seems like a valuable compiler
optimization, if that is even possible.

Re: So why doesn't popFront return an element?

[Jonathan M Davis]

> I'm trying to understand the design of ranges. Why does popFront only set
> the front() property to return the next element in the range? Why not
> return the element in the call to popFront right away?
> 
> For example code like this (which doesn't work since popFront doesn't
> return): void main()
> {
> int[] a = [1, 2];
> auto b = a.popFront;
> assert(a == [2]);
> assert(b == 1);
> }
> 
> Isn't it wasteful to have to call both popFront() and front() to
> simultaneously remove an element from a range and return it? I mean it's
> an extra function call, right?

Often, it would be wasteful to have popFront return an element, since it's 
perfectly legitimate to call popFront without wanting to ever see front. If 
the type of front is a struct, then it would have to be copied which could 
cost more than a function call. And both front and popFront would typically be 
inlined anyway (at least as long as you compile with -inline), so it's 
unlikely that it really costs you a function call anyway.

Really, however, I believe that it's a matter of functionality. front and 
popFront do two very different things. One of them gives you the first 
element; the other removes the first element. You can call them both 
separately without wanting to do the other. There are plenty of cases where 
you want to call popFront multiple times without ever calling front, and there 
are plenty of cases where you want to call front without calling popFront. It 
_definitely_ would be a problem if front were removed in favor of having 
popFront return the front element, but even if you kept front and just made 
popFront return an element, it's conflating two separate operations into one 
function, which often is a bad idea.

In the case of popFront, I often call popFront without wanting to look at 
front immediately if at all, and in most cases where you _do_ want to look at 
front every time, you're probably using a foreach loop and not calling 
popFront directly anyway. So, making popFront return an element wouldn't help 
you much.

So, really, there's no need to make popFront return front, it's more likely to 
be _less_ efficient to do that, rather than more, and it's conflating two 
separate operations.

I see little to no benefit to making popFront return anything, and it could be 
detrimental for it to.

- Jonathan M Davis

Re: So why doesn't popFront return an element?

[Jesse Phillips]

Andrej Mitrovic Wrote:

> Isn't it wasteful to have to call both popFront() and front() to 
> simultaneously remove an element from a range and return it? I mean it's an 
> extra function call, right?

Isn't also a waste to return something that isn't going to be used? There are 
times it is important to just advance and either skip it or use the value in 
another location.

In either situation I think the overhead is minimal.

So why doesn't popFront return an element?

[Andrej Mitrovic]

I'm trying to understand the design of ranges. Why does popFront only set the 
front() property to return the next element in the range? Why not return the 
element in the call to popFront right away?

For example code like this (which doesn't work since popFront doesn't return):
void main()
{
int[] a = [1, 2];
auto b = a.popFront;
assert(a == [2]);
assert(b == 1);
}

Isn't it wasteful to have to call both popFront() and front() to simultaneously 
remove an element from a range and return it? I mean it's an extra function 
call, right?

Re: Unmatched static array size assignment

[bearophile]

Andrej Mitrovic:

> We'll either get a compiler with a better warning system

In that bug report I ask for an error, not a warning.


> or we'll make some kind of Lint tool for D.

Eventually some lint tools will surely be written for D, but lot of people 
don't use lints. What I am looking here is a little change in the language. The 
full proposal has three parts:

Refuse array lengths that don't match:
int[2] a = [1]; // compile-time error
main() {}

Introduce [$] to infer the array length at the definition point:
int[$] a = [1]; // OK
main() {}

And introduce a syntax like "..." for the uncommon partial specification 
situations:
int[4] a = [1, 2, ...]; // OK
main() {}

Bye,
bearophile

Re: Unmatched static array size assignment

[Andrej Mitrovic]

Yeah, I don't have a lot of votes left, in fact I only have one left. :s

I think we're basically on our own when it comes to these kinds of
issues. We'll either get a compiler with a better warning system
(maybe GDC.. DDMD in the future), or we'll make some kind of Lint tool
for D. The latter approach might even be better since you could
probably customize such a tool to fit your needs.

Re: Unmatched static array size assignment

[bearophile]

Andrej Mitrovic:

> void main()
> {
> static string[2] szFormat = ["%s, %s"];
> }
> 
> This compiles, but this is buggy code.

Please vote this old bug report of mine, about this problem:
http://d.puremagic.com/issues/show_bug.cgi?id=3849

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=481

Bye,
bearophile

Re: Unmatched static array size assignment

[Andrej Mitrovic]

Andrej Mitrovic Wrote:

> So in retrospect:
> // no error until a call to writefln,
> // which could still potentially not fail => possible bugs
> string[2] szFormat = ["%s, %s"];
> 
> // error at runtime, the compiler could have caught this though
> static string[2] szFormat2 = ["%s, %s"];
> 

Sorry, I've accidentally reversed the two. Fixed:
// no error until a call to writefln,
// which could still potentially not fail => possible bugs
static string[2] szFormat = ["%s, %s"];
 
// error at runtime, the compiler could have caught this though
string[2] szFormat2 = ["%s, %s"];

Unmatched static array size assignment

[Andrej Mitrovic]

Code:

void main()
{
static string[2] szFormat = ["%s, %s"];
}

This compiles, but this is buggy code. The first declaration should have been:
static string[2] szFormat = ["%s", "%s"];

I can't tell whether the first case is legit code. You might *want* to 
initialize all the elements with the same single initializer. But in that case, 
you would write:
static string[2] szFormat = "%s, ";

So, without the '[]'.

If you remove static from the declaration (it's still a static array, I know!), 
you'll get a nice runtime error:
object.Exception@src\rt\arraycat.d(31): lengths don't match for array copy

Actually it's not a nice error message since you can't even tell what causes 
the error.

So in retrospect:
// no error until a call to writefln,
// which could still potentially not fail => possible bugs
string[2] szFormat = ["%s, %s"];

// error at runtime, the compiler could have caught this though
static string[2] szFormat2 = ["%s, %s"];

Re: How do I flush the output of write?

[Steven Schveighoffer]

On Wed, 13 Apr 2011 15:41:07 -0400, Andrej Mitrovic  
 wrote:



I kept trying to do flush(stdout), but I had the syntax wrong I guess. :)


fflush(stdout) is the way to do it in C, so that's probably where you got  
it from.


in D, stdout is actually a File struct, which contains a flush method.

-Steve

Re: How do I flush the output of write?

[Andrej Mitrovic]

I kept trying to do flush(stdout), but I had the syntax wrong I guess. :)

Thx.

Re: How do I flush the output of write?

[Steven Schveighoffer]

On Wed, 13 Apr 2011 14:00:04 -0400, Andrej Mitrovic  wrote:

Calling write doesn't automatically flush the output to the screen. Is  
there a function I could call to do it manually? writeln doesn't suffer  
from this problem.


stdout.flush();

-Steve

How do I flush the output of write?

[Andrej Mitrovic]

Calling write doesn't automatically flush the output to the screen. Is there a 
function I could call to do it manually? writeln doesn't suffer from this 
problem.

Re: Else clauses for loops

[bearophile]

Bernard Helyer:

> You could wrap the loop in an if clause:
> 
> if (condition) while (true) {
> // ...
> } else {
> // ...
> }

This is the semantics of the else clause of Python for (and while) loops:

bool broken = false;
for (...) {
if (...) {
broken = true;
break;
}
}
if (!broken) {
 ...
}

I agree with BCS in the bug 2304, I'd like something more semantically 
descriptive instead of just an "else".
It's handy, I use it now and then in Python, but I am able to live without it 
in D.

Bye,
bearophile

Re: "Before and after" in contracts?

[bearophile]

Magnus Lie Hetland:

> For me, I'd be happy if I could simply declare and initialize the 
> variables myself somehow before the body is executed, and then check 
> them in the out-block.

Indeed, as you may have seen in the linked threads, this was the main proposal 
in D. For me it's acceptable, if it works.


> Is there a feature request on this that I could add my vote to? If not, 
> perhaps it's worth creating one?

I don't know of any feature request on this (I have opened bug 5027 about ghost 
fields, but now I am less interested in them), so search for it in Bugzilla. If 
you don't find it, then it's worth adding, with plenty of explanations of its 
purposes and ideas of ways to implement it.


> If not, I guess I could just post a "bump" to the D group :-}

I think lately Walter has lost a bit of enthusiasm regarding Design By 
Contract. A little bump once in a while is acceptable, to show that some people 
care for this sub-feature. If you want to (gently) bump then you may do after 
writing the bug report and showing the bug report number.

Bye,
bearophile

Re: Semicolon can be left out after do-while

[Emil Madsen]

On 13 April 2011 16:17, Kai Meyer  wrote:

> On 04/13/2011 07:44 AM, Emil Madsen wrote:
>
>> On 13 April 2011 14:36, Steven Schveighoffer > > wrote:
>>
>>On Tue, 12 Apr 2011 18:00:40 -0400, spir >> wrote:
>>
>>On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:
>>
>>On Tue, 12 Apr 2011 17:21:57 -0400, spir
>>mailto:denis.s...@gmail.com>> wrote:
>>
>>On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
>>
>>int main(){
>>int a,b;
>>do{
>>scanf("%d %d",&a,&b);
>>}while(a>return 0;
>>}
>>
>>The grammar specifies this correctly, but then
>>again, the example uses the
>>semicolon.
>>(
>> http://www.digitalmars.com/d/2.0/statement.html#DoStatement)
>>[...]
>>I think the grammar should be changed...
>>
>>
>>yop!
>>
>>This is almost as bad as go's
>>requirement for if statement opening block to be on
>>the same line...
>>
>>
>>why? I like Go's syntactuc diffs. (except for its
>>"multi-for")
>>
>>
>>in Go, this:
>>
>>if(x)
>>{
>>gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
>>}
>>
>>is equivalent to this in D:
>>
>>if(x)
>>{
>>}
>>
>>writeln("hello");
>>
>>This is frankly unforgivable IMO.
>>
>>Of course it's fixable, but the attitude that "the coder
>>should know better"
>>doesn't really make me comfortable with it. And I hate the
>>"brace on the same
>>line" format (but this of course is not a real argument
>>against it).
>>
>>
>>Oh, that's what you meant! I find this a Good Thing, in that it
>>enforces one bracing style (the right one, that does not eats
>>one more line for just a '{').
>>
>>
>>No, it doesn't enforce anything.  The above compiles and runs.  What
>>it does is introduce subtle bugs.
>>
>>The way to fix it is to make the above an error.
>>
>>
>>About knowing or not about this (non/mis/-)feature, it's written
>>down, and clearly, in all Go docs I've read. And one cannot miss
>>it for very long anyway ;-)
>>
>>
>>I know that if(xyz); is not *ever* what I meant, but in C it
>>compiles.  However, in D, it tells me I shouldn't do that.  What
>>results is less bugs because I can't make that mistake without the
>>compiler complaining.
>>
>>I'm not saying that the spec isn't well defined, or the manual isn't
>>clear, what I'm saying is, the attitude reflected in the rule is
>>that greater burden is put on the developer to make sure they follow
>>the rules without compiler enforcement.  It makes me want to not use
>>Go.  And in fact, I will probably never use it as long as this rule
>>is in place.
>>
>>
>>Maybe, if not done already, a line starting with an opening
>>brace should generate a parsing error.
>>
>>
>>Typically this is used to create a new scope in C/D/Java/C#.  This
>>allows declaring temporary variables, not sure how it is in Go, but
>>I'd assume something similar.
>>
>>-Steve
>>
>>
>>
>> Does D throw an error at; if(expression && expression)*; *or only at
>> if(expression);
>> Because you could actually use the first one, alike this:
>> 
>> #include 
>>
>> bool test()
>> {
>> printf("test\n");
>> return false;
>> }
>>
>> bool test2()
>> {
>> printf("test2\n");
>> return true;
>> }
>>
>> int main()
>> {
>> if(test() && test2());
>> }
>> 
>> Output = "test"
>> if test returns true, then: Output = "test" + "test2"
>>
>> Simply because its conditional, and if the first one fails, why bother
>> evaluating the rest?
>>
>> --
>>
>> // Yours sincerely
>> // Emil 'Skeen' Madsen
>>
>
> I would argue that the more correct way to do this would be to separate the
> statements that are used in the condition from the statements that are not
> used in the condition.
>
> if(test())
>test2();
>
> Since test2's return statement isn't used for anything means to me that it
> doesn't belong in the conditional statement.
>

Well I agree that its more correct for the case posted, but it can just get
somewhat messy, if your having a mix of conditionals say '&&' and '||'.
Even tho its not really good style, some of the people I study with use this
trick quite a lot converting functional programs, apparently (not my area of
expertise).

But surely I would go with your approach too, but if your having a deep
nesting of conditionals, I guess that could give some heavily nested code
too. (Atleast

Re: implib

[Tine Sukljan]

On 4/13/11 3:59 PM, Bernard Helyer wrote:

implib is for working with Windows libraries. Why on earth do you need it
on OS X?


In the examples that comes with GLFW library there are some def files. 
And the Makefile uses implib to get the lib files from them. So I 
searched for implib.

Re: Semicolon can be left out after do-while

[Kai Meyer]

On 04/13/2011 07:44 AM, Emil Madsen wrote:

On 13 April 2011 14:36, Steven Schveighoffer mailto:schvei...@yahoo.com>> wrote:

On Tue, 12 Apr 2011 18:00:40 -0400, spir mailto:denis.s...@gmail.com>> wrote:

On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:

On Tue, 12 Apr 2011 17:21:57 -0400, spir
mailto:denis.s...@gmail.com>> wrote:

On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:

int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(ahttp://www.digitalmars.com/d/2.0/statement.html#DoStatement)
[...]
I think the grammar should be changed...


yop!

This is almost as bad as go's
requirement for if statement opening block to be on
the same line...


why? I like Go's syntactuc diffs. (except for its
"multi-for")


in Go, this:

if(x)
{
gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
}

is equivalent to this in D:

if(x)
{
}

writeln("hello");

This is frankly unforgivable IMO.

Of course it's fixable, but the attitude that "the coder
should know better"
doesn't really make me comfortable with it. And I hate the
"brace on the same
line" format (but this of course is not a real argument
against it).


Oh, that's what you meant! I find this a Good Thing, in that it
enforces one bracing style (the right one, that does not eats
one more line for just a '{').


No, it doesn't enforce anything.  The above compiles and runs.  What
it does is introduce subtle bugs.

The way to fix it is to make the above an error.


About knowing or not about this (non/mis/-)feature, it's written
down, and clearly, in all Go docs I've read. And one cannot miss
it for very long anyway ;-)


I know that if(xyz); is not *ever* what I meant, but in C it
compiles.  However, in D, it tells me I shouldn't do that.  What
results is less bugs because I can't make that mistake without the
compiler complaining.

I'm not saying that the spec isn't well defined, or the manual isn't
clear, what I'm saying is, the attitude reflected in the rule is
that greater burden is put on the developer to make sure they follow
the rules without compiler enforcement.  It makes me want to not use
Go.  And in fact, I will probably never use it as long as this rule
is in place.


Maybe, if not done already, a line starting with an opening
brace should generate a parsing error.


Typically this is used to create a new scope in C/D/Java/C#.  This
allows declaring temporary variables, not sure how it is in Go, but
I'd assume something similar.

-Steve



Does D throw an error at; if(expression && expression)*; *or only at
if(expression);
Because you could actually use the first one, alike this:

#include 

bool test()
{
 printf("test\n");
 return false;
}

bool test2()
{
 printf("test2\n");
 return true;
}

int main()
{
 if(test() && test2());
}

Output = "test"
if test returns true, then: Output = "test" + "test2"

Simply because its conditional, and if the first one fails, why bother
evaluating the rest?

--
// Yours sincerely
// Emil 'Skeen' Madsen


I would argue that the more correct way to do this would be to separate 
the statements that are used in the condition from the statements that 
are not used in the condition.


if(test())
test2();

Since test2's return statement isn't used for anything means to me that 
it doesn't belong in the conditional statement.

Re: Semicolon can be left out after do-while

[Steven Schveighoffer]

On Wed, 13 Apr 2011 09:44:54 -0400, Emil Madsen  wrote:


On 13 April 2011 14:36, Steven Schveighoffer  wrote:




I know that if(xyz); is not *ever* what I meant, but in C it compiles.
 However, in D, it tells me I shouldn't do that.  What results is less  
bugs

because I can't make that mistake without the compiler complaining.


Does D throw an error at; if(expression && expression)*; *or only at
if(expression);
Because you could actually use the first one, alike this:

#include 

bool test()
{
printf("test\n");
return false;
}

bool test2()
{
printf("test2\n");
return true;
}

int main()
{
if(test() && test2());
}

Output = "test"
if test returns true, then: Output = "test" + "test2"

Simply because its conditional, and if the first one fails, why bother
evaluating the rest?


if(condition1 && condition2); is an error.

However, an expression can be a statement:

condition1 && condition2;

Note, you can get around the limitation if that *really is* what you meant  
by doing:


if(expression) {}

An if statement is hard to justify for this, but I can see a while or for  
loop making sense here.


-Steve

Re: Semicolon can be left out after do-while

[Andrej Mitrovic]

On 4/13/11, Steven Schveighoffer  wrote:
> I know that if(xyz); is not *ever* what I meant, but in C it compiles.
> However, in D, it tells me I shouldn't do that.

I've been caught by DMD doing this a couple of times. It saved my
butt. Thanks, Walter!

Re: implib

[Bernard Helyer]

implib is for working with Windows libraries. Why on earth do you need it 
on OS X?

Re: Semicolon can be left out after do-while

[Emil Madsen]

On 13 April 2011 14:36, Steven Schveighoffer  wrote:

> On Tue, 12 Apr 2011 18:00:40 -0400, spir  wrote:
>
>  On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:
>>
>>> On Tue, 12 Apr 2011 17:21:57 -0400, spir  wrote:
>>>
>>>  On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:

  int main(){
> int a,b;
> do{
> scanf("%d %d",&a,&b);
> }while(a return 0;
> }
>
> The grammar specifies this correctly, but then again, the example uses
> the
> semicolon. (
> http://www.digitalmars.com/d/2.0/statement.html#DoStatement)
> [...]
> I think the grammar should be changed...
>

 yop!

  This is almost as bad as go's
> requirement for if statement opening block to be on the same line...
>

 why? I like Go's syntactuc diffs. (except for its "multi-for")

>>>
>>> in Go, this:
>>>
>>> if(x)
>>> {
>>> gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
>>> }
>>>
>>> is equivalent to this in D:
>>>
>>> if(x)
>>> {
>>> }
>>>
>>> writeln("hello");
>>>
>>> This is frankly unforgivable IMO.
>>>
>>> Of course it's fixable, but the attitude that "the coder should know
>>> better"
>>> doesn't really make me comfortable with it. And I hate the "brace on the
>>> same
>>> line" format (but this of course is not a real argument against it).
>>>
>>
>> Oh, that's what you meant! I find this a Good Thing, in that it enforces
>> one bracing style (the right one, that does not eats one more line for just
>> a '{').
>>
>
> No, it doesn't enforce anything.  The above compiles and runs.  What it
> does is introduce subtle bugs.
>
> The way to fix it is to make the above an error.
>
>
>  About knowing or not about this (non/mis/-)feature, it's written down, and
>> clearly, in all Go docs I've read. And one cannot miss it for very long
>> anyway ;-)
>>
>
> I know that if(xyz); is not *ever* what I meant, but in C it compiles.
>  However, in D, it tells me I shouldn't do that.  What results is less bugs
> because I can't make that mistake without the compiler complaining.
>
> I'm not saying that the spec isn't well defined, or the manual isn't clear,
> what I'm saying is, the attitude reflected in the rule is that greater
> burden is put on the developer to make sure they follow the rules without
> compiler enforcement.  It makes me want to not use Go.  And in fact, I will
> probably never use it as long as this rule is in place.
>
>
>  Maybe, if not done already, a line starting with an opening brace should
>> generate a parsing error.
>>
>
> Typically this is used to create a new scope in C/D/Java/C#.  This allows
> declaring temporary variables, not sure how it is in Go, but I'd assume
> something similar.
>
> -Steve
>


Does D throw an error at; if(expression && expression)*; *or only at
if(expression);
Because you could actually use the first one, alike this:

#include 

bool test()
{
printf("test\n");
return false;
}

bool test2()
{
printf("test2\n");
return true;
}

int main()
{
if(test() && test2());
}

Output = "test"
if test returns true, then: Output = "test" + "test2"

Simply because its conditional, and if the first one fails, why bother
evaluating the rest?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Else clauses for loops

[Bernard Helyer]

You could wrap the loop in an if clause:

if (condition) while (true) {
// ...
} else {
// ...
}

Re: "Before and after" in contracts?

[Magnus Lie Hetland]

On 2011-04-11 18:42:18 +0200, bearophile said:

Your need is perfectly natural it's named "old" values or prestate in 
contract programming, and currently it's probably the biggest hole in 
the D contract programming. It was discussed three or four times, like:

[snip]

Interesting.


I don't know if Walter is willing someday to fill this hole of the D DbC.


It seems the prestate thing hasn't been done because it's a bit 
ambitious? I mean, the automatic part (which would be totally 
*kick-ass*, of course).


For me, I'd be happy if I could simply declare and initialize the 
variables myself somehow before the body is executed, and then check 
them in the out-block.


In my opinion is good to bugger now and then the main D newsgroup about 
this, to help Walter&Andrei understand that there are some programmers 
that care for this feature of DbC.


Is there a feature request on this that I could add my vote to? If not, 
perhaps it's worth creating one?


If not, I guess I could just post a "bump" to the D group :-}

--
Magnus Lie Hetland
http://hetland.org

Else clauses for loops

[Magnus Lie Hetland]

Hi!

A feature I use surprisingly often in Python is the else clause on 
loops. Is there something similar in D? Basically, the idea is that 
your loop is "looking for something" (or some condition), and that 
you'll break out of it if you find what you're looking for. If no break 
occurs, the else clause is executed.


It makes for quite clean code in many cases, IMO. The alternative can 
be a flag variable, I guess, or a goto-statement (to right after the 
"else" bit) instead of a break. Or put it in a function, and use a 
return instead of a break ... or use scope() somehow, perhaps.


I see that the feature has been requested a few years ago [1], so there 
might not be that much demand for this sort of thing. Is there perhaps 
a D idiom here already?


[1] http://d.puremagic.com/issues/show_bug.cgi?id=2304

--
Magnus Lie Hetland
http://hetland.org

Re: Semicolon can be left out after do-while

[Steven Schveighoffer]

On Tue, 12 Apr 2011 18:00:40 -0400, spir  wrote:


On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:

On Tue, 12 Apr 2011 17:21:57 -0400, spir  wrote:


On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:


int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(aThe grammar specifies this correctly, but then again, the example  
uses the
semicolon.  
(http://www.digitalmars.com/d/2.0/statement.html#DoStatement)

[...]
I think the grammar should be changed...


yop!


This is almost as bad as go's
requirement for if statement opening block to be on the same line...


why? I like Go's syntactuc diffs. (except for its "multi-for")


in Go, this:

if(x)
{
gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
}

is equivalent to this in D:

if(x)
{
}

writeln("hello");

This is frankly unforgivable IMO.

Of course it's fixable, but the attitude that "the coder should know  
better"
doesn't really make me comfortable with it. And I hate the "brace on  
the same

line" format (but this of course is not a real argument against it).


Oh, that's what you meant! I find this a Good Thing, in that it enforces  
one bracing style (the right one, that does not eats one more line for  
just a '{').


No, it doesn't enforce anything.  The above compiles and runs.  What it  
does is introduce subtle bugs.


The way to fix it is to make the above an error.

About knowing or not about this (non/mis/-)feature, it's written down,  
and clearly, in all Go docs I've read. And one cannot miss it for very  
long anyway ;-)


I know that if(xyz); is not *ever* what I meant, but in C it compiles.   
However, in D, it tells me I shouldn't do that.  What results is less bugs  
because I can't make that mistake without the compiler complaining.


I'm not saying that the spec isn't well defined, or the manual isn't  
clear, what I'm saying is, the attitude reflected in the rule is that  
greater burden is put on the developer to make sure they follow the rules  
without compiler enforcement.  It makes me want to not use Go.  And in  
fact, I will probably never use it as long as this rule is in place.


Maybe, if not done already, a line starting with an opening brace should  
generate a parsing error.


Typically this is used to create a new scope in C/D/Java/C#.  This allows  
declaring temporary variables, not sure how it is in Go, but I'd assume  
something similar.


-Steve