www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.039 and 2.023 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Faster long divides!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.039.zip



http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.023.zip
Jan 06 2009
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
2009/1/7 Walter Bright <newshound1 digitalmars.com>:

 Faster long divides!



No progress on "faster long compiles" though?

--bb
Jan 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 (and an Internal error: ..\ztc\cod4.c 357 on one 
 of source code files) :)



Bugzilla report, pls!
Jan 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 Bugzilla report, pls!



 Already done.



Thanks!
Jan 06 2009
prev sibling parent Extrawurst <spam extrawurst.org> writes:
Denis Koroskin wrote:

 On Wed, 07 Jan 2009 07:03:27 +0300, Bill Baxter <wbaxter gmail.com> wrote:
 

 2009/1/7 Walter Bright <newshound1 digitalmars.com>:

 Faster long divides!



 No progress on "faster long compiles" though?

 --bb



 Small statistics on compilation time of my small project:
 
 DMD2.021 - 16 seconds
 DMD2.022 - 46 seconds
 DMD2.023 - 15 seconds (and an Internal error: ..\ztc\cod4.c 357 on one 
 of source code files) :)




Wow this one really sucks. For me this makes nearly every D2 using 
project unbuildable ;(
Jan 07 2009
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Jan 6, 2009 at 11:03 PM, Bill Baxter <wbaxter gmail.com> wrote:

 2009/1/7 Walter Bright <newshound1 digitalmars.com>:

 Faster long divides!



 No progress on "faster long compiles" though?

 --bb



The D2 changelog says that he undid the fix to 2500, which might be
the cause.  But no word on whether it was the cause, or if D1 got the
revert as well.
Jan 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 The D2 changelog says that he undid the fix to 2500, which might be
 the cause.  But no word on whether it was the cause, or if D1 got the
 revert as well.



D1 got the same reversion.
Jan 06 2009
parent reply torhu <no spam.invalid> writes:
On 07.01.2009 05:51, Walter Bright wrote:

 Jarrett Billingsley wrote:

  The D2 changelog says that he undid the fix to 2500, which might be
  the cause.  But no word on whether it was the cause, or if D1 got the
  revert as well.



 D1 got the same reversion.



1.039 hangs while trying to build my DWT app, just like 1.038 did.  It 
just seems to never finish, so I kill it after a while.  Don't know if 
it's related to this issue or not.
Jan 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
torhu wrote:

 1.039 hangs while trying to build my DWT app, just like 1.038 did.  It 
 just seems to never finish, so I kill it after a while.  Don't know if 
 it's related to this issue or not.



I need a reproducible example.
Jan 07 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Jan 7, 2009 at 1:04 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Tue, Jan 6, 2009 at 11:03 PM, Bill Baxter <wbaxter gmail.com> wrote:

 2009/1/7 Walter Bright <newshound1 digitalmars.com>:

 Faster long divides!



 No progress on "faster long compiles" though?

 --bb



 The D2 changelog says that he undid the fix to 2500, which might be
 the cause.  But no word on whether it was the cause, or if D1 got the
 revert as well.



Guess I'll give it a try then.

--bb
Jan 06 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:


 Faster long divides!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.039.zip



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



Nice!

Before you start closing fixed issues, I'd like to ask you add short fix
discription wherever possible, because it is sometimes hard to understand what
is fixed and how, especially in ambiguous cases.

BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007).
Congratulations!
Jan 06 2009
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Faster long divides!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.039.zip



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



 Nice!

 Before you start closing fixed issues, I'd like to ask you add short fix
 discription wherever possible, because it is sometimes hard to understand
 what is fixed and how, especially in ambiguous cases.

 BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007).
 Congratulations!



Whoa!  I would have believed 1 year.  Doesn't seem like 2.

--bb
Jan 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Jan 2009 07:11:52 +0300, Bill Baxter <wbaxter gmail.com> wrote:


 On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin <2korden gmail.com> wrote:

 On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Faster long divides!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.039.zip



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



 Nice!

 Before you start closing fixed issues, I'd like to ask you add short fix
 discription wherever possible, because it is sometimes hard to  
 understand
 what is fixed and how, especially in ambiguous cases.

 BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in  
 2007).
 Congratulations!



 Whoa!  I would have believed 1 year.  Doesn't seem like 2.

 --bb



It will be a year for D2 in ten days.
Jan 06 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Jan 2009 07:16:38 +0300, Denis Koroskin <2korden gmail.com> wrote:


 On Wed, 07 Jan 2009 07:11:52 +0300, Bill Baxter <wbaxter gmail.com>  
 wrote:


 On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin <2korden gmail.com>  
 wrote:

 On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Faster long divides!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.039.zip



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



 Nice!

 Before you start closing fixed issues, I'd like to ask you add short  
 fix
 discription wherever possible, because it is sometimes hard to  
 understand
 what is fixed and how, especially in ambiguous cases.

 BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in  
 2007).
 Congratulations!



 Whoa!  I would have believed 1 year.  Doesn't seem like 2.

 --bb



 It will be a year for D2 in ten days.



Ahhhmm.. 2 years as well, sorry for confusion.
Jan 06 2009
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Jan 6, 2009 at 11:51 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 The D2 changelog says that he undid the fix to 2500, which might be
 the cause.  But no word on whether it was the cause, or if D1 got the
 revert as well.



 D1 got the same reversion.



Wee!
Jan 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Jan 2009 07:03:27 +0300, Bill Baxter <wbaxter gmail.com> wrote:


 2009/1/7 Walter Bright <newshound1 digitalmars.com>:

 Faster long divides!



 No progress on "faster long compiles" though?

 --bb



Small statistics on compilation time of my small project:

DMD2.021 - 16 seconds
DMD2.022 - 46 seconds
DMD2.023 - 15 seconds (and an Internal error: ..\ztc\cod4.c 357 on one of
source code files) :)
Jan 06 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
V 1.039 compiles my dlibs fine, but I have not timed the compilation times yet.

The long divides are much faster than before and almost as the ones done by
GCC, good work.

The timings of the division benchmark I have shown last time:
  DMD1.038: 63.7 s
  DMD1.039: 12.2 s
  GCC4.2.1: 11.1 s

Regarding the pure optimizations done by D2, how can the LDC compiler do the
same? Are them done by the front-end?

Bye,
bearophile
Jan 06 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 The long divides are much faster than before and almost as the ones
 done by GCC, good work.
 
 The timings of the division benchmark I have shown last time: 
 DMD1.038: 63.7 s DMD1.039: 12.2 s GCC4.2.1: 11.1 s
 
 Regarding the pure optimizations done by D2, how can the LDC compiler
 do the same? Are them done by the front-end?



I changed nothing with the compiler. I just rewrote the runtime long 
division function.
Jan 06 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Jan 7, 2009 at 2:10 PM, bearophile <bearophileHUGS lycos.com> wrote:

 V 1.039 compiles my dlibs fine, but I have not timed the compilation times yet.

 The long divides are much faster than before and almost as the ones done by
GCC, good work.

 The timings of the division benchmark I have shown last time:
  DMD1.038: 63.7 s
  DMD1.039: 12.2 s
  GCC4.2.1: 11.1 s

 Regarding the pure optimizations done by D2, how can the LDC compiler do the
same? Are them done by the front-end?



Rockin'.  Compile times seem unchanged wrt DMD 1.037 here too.
Partial IFTI here I come!

-- bb
Jan 06 2009
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Jan 7, 2009 at 12:31 AM, Walter Bright
<newshound1 digitalmars.com> wrote:


 Regarding the pure optimizations done by D2, how can the LDC compiler
 do the same? Are them done by the front-end?



 I changed nothing with the compiler. I just rewrote the runtime long
 division function.



Can you say "non sequitur"?

He asked about "pure" optimization, not long division.
Jan 07 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Jan 2009 08:34:10 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:


 Denis Koroskin wrote:

 (and an Internal error: ..\ztc\cod4.c 357 on one of source code files)  
 :)



 Bugzilla report, pls!



Already done.
Jan 06 2009
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
It appears that you've also fixed 
http://d.puremagic.com/issues/show_bug.cgi?id=2359 :D /* which might've 
been the same issue as http://d.puremagic.com/issues/show_bug.cgi?id=2527 */

Perhaps I can finally update from 1.031 :> Thanks a bunch!

-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Jan 07 2009
prev sibling next sibling parent reply redsea <redsea 163.com> writes:
I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII variable
destructor is not called) has been fixed, Great !

I have some questions when I check dstress suite and Bugzilla.

In Bugzilla 99,  according to test case:

int main(){
	int i;
	
label: 
	{
		scope(exit) i++;
		i=3;
	}

	if(i != 4){
		assert(0);
	}

	return 0;
}

You said:

The test case behaves as expected, because labels do not introduce a new scope
when followed by { }.


Then I check the online manual, and found:

labels, scope(), pragma, condition compile(version/debug/static if) would be
followed by NonScopeStatement.

It is easy to understand scope/condition compile followed by a
NonScopeStatement, 
but what is the meaning of  "Labeled Statements"  + NonScopeStatement ?  

If I understand the rule I would make least mistakes, so can you do some
explain for me ?  Thanks.





Walter Bright Wrote:


 Faster long divides!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.039.zip
 
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.023.zip
Jan 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
redsea wrote:

 I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
 variable destructor is not called) has been fixed, Great !
 
 I have some questions when I check dstress suite and Bugzilla.
 
 In Bugzilla 99,  according to test case:
 
 int main(){ int i;  label: { scope(exit) i++; i=3; }
 
 if(i != 4){ assert(0); }
 
 return 0; }
 
 You said:
 
 The test case behaves as expected, because labels do not introduce a
 new scope when followed by { }.
 
 
 Then I check the online manual, and found:
 
 labels, scope(), pragma, condition compile(version/debug/static if)
 would be followed by NonScopeStatement.
 
 It is easy to understand scope/condition compile followed by a
 NonScopeStatement, but what is the meaning of  "Labeled Statements"
 + NonScopeStatement ?



A NonScopeStatement is a statement that, even if it has { }, does not 
introduce a new scope.


 
 If I understand the rule I would make least mistakes, so can you do
 some explain for me ?  Thanks.
Jan 07 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


 redsea wrote:

 I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
 variable destructor is not called) has been fixed, Great !
 
 I have some questions when I check dstress suite and Bugzilla.
 
 In Bugzilla 99,  according to test case:
 
 int main(){ int i;  label: { scope(exit) i++; i=3; }
 
 if(i != 4){ assert(0); }
 
 return 0; }
 
 You said:
 
 The test case behaves as expected, because labels do not introduce a
 new scope when followed by { }.
 
 
 Then I check the online manual, and found:
 
 labels, scope(), pragma, condition compile(version/debug/static if)
 would be followed by NonScopeStatement.
 
 It is easy to understand scope/condition compile followed by a
 NonScopeStatement, but what is the meaning of  "Labeled Statements"
 + NonScopeStatement ?



 A NonScopeStatement is a statement that, even if it has { }, does not 
 introduce a new scope.



I don't think this answers their question. What curly braces mean after a label
is clearly a design decision that you made when writing D. It seems that the
choice is the opposite of what people expect. Can you explain why it should be
NonScope?
 

 
 If I understand the rule I would make least mistakes, so can you do
 some explain for me ?  Thanks.
Jan 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 Jason House wrote:

 I don't think this answers their question. What curly braces mean
 after a label is clearly a design decision that you made when writing
 D. It seems that the choice is the opposite of what people expect.
 Can you explain why it should be NonScope?



 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?



version (foo)
{
     int i;
}
...
version (foo)
{
     bar(i);
}

Writing labeled block statements is something more likely to be 
generated by an automated D code generator, and it's convenient to be 
able to control if a scope is generated or not.
Jan 07 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
<snip>

 Writing labeled block statements is something more likely to be 
 generated by an automated D code generator, 



I still don't get it.


 and it's convenient to be able to control if a scope is generated or not.



To force a block to create a scope:

{{
     ...
}}

To force a block not to create a scope:

version (all) {
     ...
}

Stewart.
Jan 10 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Brad Roberts:


 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?



Recently I have shown a possible syntax for express general unsafeties in D
code, for example:

unsafe (bounds, overflow) {
  ... // here there's no array bound checks, not integral overflow checks
}

I think this safe(...){...} and unsafe(...){...} don't need to form a scope,
like static if.

--------------------------

Bill Baxter:


I do think it would be nice if there was some kind of alternate non-scope block
delimiter syntax in D. When you have static ifs mixed with regular ifs and
versions it starts to be pretty difficult to see the flow of things. Something
like



     some stuff
::<

Probably I don't understand that syntax. A more full example may help me
understand it. But if I understand it correctly, then I don't like that syntax.
The {} add a little of noise, but help you know for sure inside where you are
(the alternative, if the indenting level are low enough is of course the Python
stile). Your style (if I understand it correctly) reminds me the way you use in
Pascal to define compiler directives in blocks of code, and it leads to
troubles compared to the static if {} of D.

Bye,
bearophile
Jan 08 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 To me it's hard to see those variable declarations as being anything
 other than scoped to the blocks they're in.
 So all I'm saying is if we could have some different delimiters for
 non-scope blocks then it might be nice, and make it easier to see when
 scopes are ending and when they are not.



*Now* I understand, and I see your point.
It's the usual problem: ASCII doesn't have enough ways to represent containers
and delimiters :-)

So if this is your original code (I have improved your indentations and
improved readability a little):

void doSomething(T)(int i) {
    if (i == 0) {
        static if (is(T == A)) {
            A.SomeAlias x;
        } else static if(is(T == B)) {
            B.SubType x;
        } else {
            T x;
        }
        
        x = ... whatever
   }
   else
        int y = x;
}


This can be the new version following your idea:

void doSomething(T)(int i) {
    if (i == 0) {
        static if (is(T == A)) ::
            A.SomeAlias x;
        :: else static if(is(T == B)) ::
            B.SubType x;
        :: else ::
            T x;
        ::
        
        x = ... whatever
   }
   else
        int y = x;
}


But the problem is that :: don't have a head and tail, so the code is even less
easy to read.

This version uses (* ... *), used in Pascal to denote comments:

void doSomething(T)(int i) {
    if (i == 0) {
        static if (is(T == A)) (*
            A.SomeAlias x;
        *) else static if(is(T == B)) (*
            B.SubType x;
        *) else (*
            T x;
        *)
        
        x = ... whatever
   }
   else
        int y = x;
}


I don't like that too, even if it's a bit better than the version with ::. 

Two other possibilities:

void doSomething(T)(int i) {
    if (i == 0) {
        static if (is(T == A)) {|
            A.SomeAlias x;
        |} else static if(is(T == B)) {|
            B.SubType x;
        |} else {|
            T x;
        |}
        
        x = ... whatever
   }
   else
        int y = x;
}


void doSomething(T)(int i) {
    if (i == 0) {
        static if (is(T == A)) {#
            A.SomeAlias x;
        #} else static if(is(T == B)) {#
            B.SubType x;
        #} else {#
            T x;
        #}
        
        x = ... whatever
   }
   else
        int y = x;
}

I don't think lot of people will appreciate those.
So the lack of different block delimiters may make this problem have no better
solution.

Bye,
bearophile
Jan 08 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:

 Bill Baxter:

 To me it's hard to see those variable declarations as being anything
 other than scoped to the blocks they're in.
 So all I'm saying is if we could have some different delimiters for
 non-scope blocks then it might be nice, and make it easier to see when
 scopes are ending and when they are not.



 *Now* I understand, and I see your point.
 It's the usual problem: ASCII doesn't have enough ways to represent containers
and delimiters :-)

 So if this is your original code (I have improved your indentations and
improved readability a little):

 void doSomething(T)(int i) {
      if (i == 0) {
          static if (is(T == A)) {
              A.SomeAlias x;
          } else static if(is(T == B)) {
              B.SubType x;
          } else {
              T x;
          }

          x = ... whatever
     }
     else
          int y = x;
 }


 This can be the new version following your idea:

 void doSomething(T)(int i) {
      if (i == 0) {
          static if (is(T == A)) ::
              A.SomeAlias x;
          :: else static if(is(T == B)) ::
              B.SubType x;
          :: else ::
              T x;
          ::

          x = ... whatever
     }
     else
          int y = x;
 }


 But the problem is that :: don't have a head and tail, so the code is even
less easy to read.

 This version uses (* ... *), used in Pascal to denote comments:

 void doSomething(T)(int i) {
      if (i == 0) {
          static if (is(T == A)) (*
              A.SomeAlias x;
          *) else static if(is(T == B)) (*
              B.SubType x;
          *) else (*
              T x;
          *)

          x = ... whatever
     }
     else
          int y = x;
 }


 I don't like that too, even if it's a bit better than the version with ::.

 Two other possibilities:

 void doSomething(T)(int i) {
      if (i == 0) {
          static if (is(T == A)) {|
              A.SomeAlias x;
          |} else static if(is(T == B)) {|
              B.SubType x;
          |} else {|
              T x;
          |}

          x = ... whatever
     }
     else
          int y = x;
 }


 void doSomething(T)(int i) {
      if (i == 0) {
          static if (is(T == A)) {#
              A.SomeAlias x;
          #} else static if(is(T == B)) {#
              B.SubType x;
          #} else {#
              T x;
          #}

          x = ... whatever
     }
     else
          int y = x;
 }

 I don't think lot of people will appreciate those.
 So the lack of different block delimiters may make this problem have no better
solution.

 Bye,
 bearophile



in C# they use the same syntax as the c pre-processor for conditional 
compilation and such even though C# doesn't have a pre-processor and the 
syntax is interpreted by the compiler. the above would be something like:

  void doSomething(T)(int i) {
       if (i == 0) {
           #if (is(T == A))
               A.SomeAlias x;
           #elif (is(T == B))
               B.SubType x;
           #else
               T x;
           #endif

           x = ... whatever
      }
      else
           int y = x;
  }

D can always revert to this kind of syntax for compile time code.
Jan 16 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:

 [snip]

 in C# they use the same syntax as the c pre-processor for conditional
 compilation and such even though C# doesn't have a pre-processor and the
 syntax is interpreted by the compiler. the above would be something like:

  void doSomething(T)(int i) {
      if (i == 0) {
          #if (is(T == A))
              A.SomeAlias x;
          #elif (is(T == B))
              B.SubType x;
          #else
              T x;
          #endif

          x = ... whatever
     }
     else
          int y = x;
  }

 D can always revert to this kind of syntax for compile time code.



 
 I kinda like that, actually, but I doubt it'll be very popular around here.
 
 --bb



The '#' has a nice connotation for anyone who's used to C/C++, given
that those statements are handled at "compile time."  The problem, of
course, is that they're really nothing like C preprocessor statements.
They have a different syntax, and completely different capabilities.
What's more, you can't mix them across statements/expressions, so I
suspect it would just cause more confusion.

Additionally, there's this:

   #endif

Unless you plan on moving all control structures to BASIC/pascal style,
I don't think it's wise to start mixing them all over the place.

I do like the idea of a "scopeless block" syntax in theory, though it's
not something that's really been an issue for me.

  -- Daniel
Jan 16 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

 void doSomething(T)(int i) {
     if (i == 0) {
         #if (is(T == A)) {
             A.SomeAlias x;
         #} else if (is(T == B)) {
             B.SubType x;
         #} else {
             T x;
         #}
  
         x = ... whatever
     }
     else
         int y = x;
 }



A different possibility is to use {# ...  #}

        static if (is(T == A)) {#
            A.SomeAlias x;
        #} else if (is(T == B)) {#

Bye,
bearophile
Jan 17 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-01-16 22:17:57 -0500, Daniel Keep <daniel.keep.lists gmail.com> said:


 The '#' has a nice connotation for anyone who's used to C/C++, given
 that those statements are handled at "compile time."  The problem, of
 course, is that they're really nothing like C preprocessor statements.
 They have a different syntax, and completely different capabilities.
 What's more, you can't mix them across statements/expressions, so I
 suspect it would just cause more confusion.
 
 Additionally, there's this:
 
    #endif
 
 Unless you plan on moving all control structures to BASIC/pascal style,
 I don't think it's wise to start mixing them all over the place.



All good reasons, but there is one more:

If you use #if in the standard D language, then it'll make it harder to 
use a real C preprocessor when you need it. D has support for #line in 
the language so that the compiler gives you error messages relative to 
the right included file and line in a preprocessor output. D doesn't 
have a preprocessor built-in, and doesn't recommand using one either, 
but it has support for it. Introducing #if in the D language would 
break that support.



 I do like the idea of a "scopeless block" syntax in theory, though it's
 not something that's really been an issue for me.



Me neither.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:gksbop$2ttr$1 digitalmars.com...

 On 2009-01-16 22:17:57 -0500, Daniel Keep <daniel.keep.lists gmail.com> 
 said:


 The '#' has a nice connotation for anyone who's used to C/C++, given
 that those statements are handled at "compile time."  The problem, of
 course, is that they're really nothing like C preprocessor statements.
 They have a different syntax, and completely different capabilities.
 What's more, you can't mix them across statements/expressions, so I
 suspect it would just cause more confusion.

 Additionally, there's this:

    #endif

 Unless you plan on moving all control structures to BASIC/pascal style,
 I don't think it's wise to start mixing them all over the place.



 All good reasons, but there is one more:

 If you use #if in the standard D language, then it'll make it harder to 
 use a real C preprocessor when you need it. D has support for #line in the 
 language so that the compiler gives you error messages relative to the 
 right included file and line in a preprocessor output. D doesn't have a 
 preprocessor built-in, and doesn't recommand using one either, but it has 
 support for it. Introducing #if in the D language would break that 
 support.



 I do like the idea of a "scopeless block" syntax in theory, though it's
 not something that's really been an issue for me.



 Me neither.



The only time I've had a problem with any scope/scopeless block issue is 
having gotten bitten once by the inability to use a mixin to declare a scope 
object (since it only lives within the mixin's own implicit scope and not 
the scope where the mixin is instantiated (as I would have expected)...which 
does seem odd now that I think about it, because an "int a", for instance, 
declared inside a mixin still outlives the mixin, even though I don't think 
that happens with an explicit block). But that doesn't really need a special 
"scopeless block" syntax to be fixed.
Jan 17 2009
prev sibling parent Nicolas <dransic free.fr> writes:
Bill Baxter Wrote:

 On Thu, Jan 8, 2009 at 5:36 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Brad Roberts:


 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?



 Recently I have shown a possible syntax for express general unsafeties in D
code, for example:

 unsafe (bounds, overflow) {
  ... // here there's no array bound checks, not integral overflow checks
 }

 I think this safe(...){...} and unsafe(...){...} don't need to form a scope,
like static if.

 --------------------------

 Bill Baxter:


I do think it would be nice if there was some kind of alternate non-scope block
delimiter syntax in D. When you have static ifs mixed with regular ifs and
versions it starts to be pretty difficult to see the flow of things. Something
like



     some stuff
 ::<

 Probably I don't understand that syntax.



 It just means curly braces. I don't really care what syntax it is,
 just something besides { and } for non-scope blocks.
 

 A more full example may help me understand it. But if I understand it
correctly, then I don't like that syntax. The {} add a little of noise, but
help you know for sure inside where you are



 Do they really help you see where you are in something like this:
 
 void Do_something(T)(int i)
 {
    if (i == 0) {
      static if (is(T==A)) {
            A.SomeAlias x;
      }
      else static if(is(T==B)) {
            B.SubType x;
      }
      else {
          T x;
       }
       x = ... whatever
    }
    else {
        int y = x;
    }
 }
 
 To me it's hard to see those variable declarations as being anything
 other than scoped to the blocks they're in.
 So all I'm saying is if we could have some different delimiters for
 non-scope blocks then it might be nice, and make it easier to see when
 scopes are ending and when they are not.
 
 --bb



I'd do:

void Do_something(T)(int i)
{
    if (i == 0)
    {
static if (is(T==A))
{
        A.SomeAlias x;
}
else static if(is(T==B))
{
        B.SubType x;
}
else
{
        T x;
}
        x = ... whatever
    }
    else
    {
        int y = x;
    }
}

it's parallel programming...
Jan 08 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 08 Jan 2009 06:25:11 +0300, Brad Roberts <braddr puremagic.com> wrote:


 Jason House wrote:

 Walter Bright Wrote:


 redsea wrote:

 I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
 variable destructor is not called) has been fixed, Great !

 I have some questions when I check dstress suite and Bugzilla.

 In Bugzilla 99,  according to test case:

 int main(){ int i;  label: { scope(exit) i++; i=3; }

 if(i != 4){ assert(0); }

 return 0; }

 You said:

 The test case behaves as expected, because labels do not introduce a
 new scope when followed by { }.


 Then I check the online manual, and found:

 labels, scope(), pragma, condition compile(version/debug/static if)
 would be followed by NonScopeStatement.

 It is easy to understand scope/condition compile followed by a
 NonScopeStatement, but what is the meaning of  "Labeled Statements"
 + NonScopeStatement ?



 introduce a new scope.



 I don't think this answers their question. What curly braces mean
 after a label is clearly a design decision that you made when writing
 D. It seems that the choice is the opposite of what people expect.
 Can you explain why it should be NonScope?



 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?

 Later,
 Brad



The only possible example I can think of is a case inside switch:

switch (i)
{
    case 42:
    {

    }
}
Jan 07 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 5:36 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Brad Roberts:


 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?



 Recently I have shown a possible syntax for express general unsafeties in D
code, for example:

 unsafe (bounds, overflow) {
  ... // here there's no array bound checks, not integral overflow checks
 }

 I think this safe(...){...} and unsafe(...){...} don't need to form a scope,
like static if.

 --------------------------

 Bill Baxter:


I do think it would be nice if there was some kind of alternate non-scope block
delimiter syntax in D. When you have static ifs mixed with regular ifs and
versions it starts to be pretty difficult to see the flow of things. Something
like



     some stuff
 ::<

 Probably I don't understand that syntax.



It just means curly braces. I don't really care what syntax it is,
just something besides { and } for non-scope blocks.


 A more full example may help me understand it. But if I understand it
correctly, then I don't like that syntax. The {} add a little of noise, but
help you know for sure inside where you are



Do they really help you see where you are in something like this:

void Do_something(T)(int i)
{
   if (i == 0) {
     static if (is(T==A)) {
           A.SomeAlias x;
     }
     else static if(is(T==B)) {
           B.SubType x;
     }
     else {
         T x;
      }
      x = ... whatever
   }
   else {
       int y = x;
   }
}

To me it's hard to see those variable declarations as being anything
other than scoped to the blocks they're in.
So all I'm saying is if we could have some different delimiters for
non-scope blocks then it might be nice, and make it easier to see when
scopes are ending and when they are not.

--bb
Jan 08 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 4:29 AM, Nicolas <dransic free.fr> wrote:

 Bill Baxter Wrote:

 On Thu, Jan 8, 2009 at 5:36 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Brad Roberts:


 Restating in the form of a question... When would you _ever_ want {...}
 to not form a scope?



 Recently I have shown a possible syntax for express general unsafeties in D
code, for example:

 unsafe (bounds, overflow) {
  ... // here there's no array bound checks, not integral overflow checks
 }

 I think this safe(...){...} and unsafe(...){...} don't need to form a scope,
like static if.

 --------------------------

 Bill Baxter:


I do think it would be nice if there was some kind of alternate non-scope block
delimiter syntax in D. When you have static ifs mixed with regular ifs and
versions it starts to be pretty difficult to see the flow of things. Something
like



     some stuff
 ::<

 Probably I don't understand that syntax.



 It just means curly braces. I don't really care what syntax it is,
 just something besides { and } for non-scope blocks.


 A more full example may help me understand it. But if I understand it
correctly, then I don't like that syntax. The {} add a little of noise, but
help you know for sure inside where you are



 Do they really help you see where you are in something like this:

 void Do_something(T)(int i)
 {
    if (i == 0) {
      static if (is(T==A)) {
            A.SomeAlias x;
      }
      else static if(is(T==B)) {
            B.SubType x;
      }
      else {
          T x;
       }
       x = ... whatever
    }
    else {
        int y = x;
    }
 }

 To me it's hard to see those variable declarations as being anything
 other than scoped to the blocks they're in.
 So all I'm saying is if we could have some different delimiters for
 non-scope blocks then it might be nice, and make it easier to see when
 scopes are ending and when they are not.

 --bb



 I'd do:

 void Do_something(T)(int i)
 {
    if (i == 0)
    {
 static if (is(T==A))
 {
        A.SomeAlias x;
 }
 else static if(is(T==B))
 {
        B.SubType x;
 }
 else
 {
        T x;
 }
        x = ... whatever
    }
    else
    {
        int y = x;
    }
 }

 it's parallel programming...



I'm having trouble resisting the urge to re-indent that code.  It
totally looks like someone got their tabs and spaces mixed up.

--bb
Jan 08 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Jan 17, 2009 at 6:26 AM, Yigal Chripun <yigal100 gmail.com> wrote:

 bearophile wrote:

 Bill Baxter:

 To me it's hard to see those variable declarations as being anything
 other than scoped to the blocks they're in.
 So all I'm saying is if we could have some different delimiters for
 non-scope blocks then it might be nice, and make it easier to see when
 scopes are ending and when they are not.



 *Now* I understand, and I see your point.
 It's the usual problem: ASCII doesn't have enough ways to represent
 containers and delimiters :-)

 So if this is your original code (I have improved your indentations and
 improved readability a little):

 [...]

 I don't think lot of people will appreciate those.
 So the lack of different block delimiters may make this problem have no
 better solution.

 Bye,
 bearophile



 in C# they use the same syntax as the c pre-processor for conditional
 compilation and such even though C# doesn't have a pre-processor and the
 syntax is interpreted by the compiler. the above would be something like:

  void doSomething(T)(int i) {
      if (i == 0) {
          #if (is(T == A))
              A.SomeAlias x;
          #elif (is(T == B))
              B.SubType x;
          #else
              T x;
          #endif

          x = ... whatever
     }
     else
          int y = x;
  }

 D can always revert to this kind of syntax for compile time code.




I kinda like that, actually, but I doubt it'll be very popular around here.

--bb
Jan 16 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 17 Jan 2009 06:17:57 +0300, Daniel Keep <daniel.keep.lists gmail.com>
wrote:


 Bill Baxter wrote:

 [snip]

 in C# they use the same syntax as the c pre-processor for conditional
 compilation and such even though C# doesn't have a pre-processor and  
 the
 syntax is interpreted by the compiler. the above would be something  
 like:

  void doSomething(T)(int i) {
      if (i == 0) {
          #if (is(T == A))
              A.SomeAlias x;
          #elif (is(T == B))
              B.SubType x;
          #else
              T x;
          #endif

          x = ... whatever
     }
     else
          int y = x;
  }

 D can always revert to this kind of syntax for compile time code.




 I kinda like that, actually, but I doubt it'll be very popular around  
 here.

 --bb



 The '#' has a nice connotation for anyone who's used to C/C++, given
 that those statements are handled at "compile time."  The problem, of
 course, is that they're really nothing like C preprocessor statements.
 They have a different syntax, and completely different capabilities.
 What's more, you can't mix them across statements/expressions, so I
 suspect it would just cause more confusion.

 Additionally, there's this:

    #endif

 Unless you plan on moving all control structures to BASIC/pascal style,
 I don't think it's wise to start mixing them all over the place.

 I do like the idea of a "scopeless block" syntax in theory, though it's
 not something that's really been an issue for me.

   -- Daniel



Well, syntax could be different:

void doSomething(T)(int i) {
    if (i == 0) {
        #if (is(T == A)) {
            A.SomeAlias x;
        #} else if (is(T == B)) {
            B.SubType x;
        #} else {
            T x;
        #}
 
        x = ... whatever
    }
    else
        int y = x;
}

But I don't see how '#' at the beginning is useful.
Jan 16 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"2527: Alias Template Params Are Always Same Type As First Instantiation 
(according to typeof(x).stringof)"

Hooray! Thanks :) That one's a big help for me.
Jan 07 2009
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Jason House wrote:

 Walter Bright Wrote:
 

 redsea wrote:

 I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
 variable destructor is not called) has been fixed, Great !

 I have some questions when I check dstress suite and Bugzilla.

 In Bugzilla 99,  according to test case:

 int main(){ int i;  label: { scope(exit) i++; i=3; }

 if(i != 4){ assert(0); }

 return 0; }

 You said:

 The test case behaves as expected, because labels do not introduce a
 new scope when followed by { }.


 Then I check the online manual, and found:

 labels, scope(), pragma, condition compile(version/debug/static if)
 would be followed by NonScopeStatement.

 It is easy to understand scope/condition compile followed by a
 NonScopeStatement, but what is the meaning of  "Labeled Statements"
 + NonScopeStatement ?



 introduce a new scope.



 I don't think this answers their question. What curly braces mean
 after a label is clearly a design decision that you made when writing
 D. It seems that the choice is the opposite of what people expect.
 Can you explain why it should be NonScope?



Restating in the form of a question... When would you _ever_ want {...}
to not form a scope?

Later,
Brad
Jan 07 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Brad,


 Restating in the form of a question... When would you _ever_ want
 {...} to not form a scope?
 



static if(foo)
{
    int i;
    float x;
}
Jan 07 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 08 Jan 2009 07:22:53 +0300, BCS <ao pathlink.com> wrote:


 Reply to Brad,


 Restating in the form of a question... When would you _ever_ want
 {...} to not form a scope?



 static if(foo)
 {
     int i;
     float x;
 }



Yeah, and version(foo) belongs here, too.
Jan 07 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 1:27 PM, Denis Koroskin <2korden gmail.com> wrote:

 On Thu, 08 Jan 2009 07:22:53 +0300, BCS <ao pathlink.com> wrote:


 Reply to Brad,


 Restating in the form of a question... When would you _ever_ want
 {...} to not form a scope?



 static if(foo)
 {
    int i;
    float x;
 }



 Yeah, and version(foo) belongs here, too.



I think I said this before, but I do think it would be nice if there
was some kind of alternate non-scope block delimiter syntax in D.
When you have static ifs mixed with regular ifs and versions it starts
to be pretty difficult to see the flow of things.
Something like

static if (x) ::
     some stuff
::


--bb
Jan 07 2009
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
BCS wrote:

 Reply to Brad,
 

 Restating in the form of a question... When would you _ever_ want
 {...} to not form a scope?



 static if(foo)
 {
    int i;
    float x;
 }
 



That and the version one are good examples.

However, the case example isn't.  It actually already forms a scope, and
that's a good thing.  Example:

switch (foo)
{
    case 1:
    {
       int i;
    }

    case 2:
       i = 0; // build error (error: undefined identifier i
}

Later,
Brad
Jan 07 2009