www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - some proposals

reply tetsuya <tetsuya_member pathlink.com> writes:
D has been a great language :)
But I dare try to give some proposals that I though might be
useful from the experience of writing about 2500 lines in D
so far.  Please think about them for a little bit ;))


1. auto-calculation of static array length

Since declaring like

int[] a = [1, 2];

gives a dynamic array, I though maybe letting

int[const] a = [1, 2];

be a static array would make enough sense.



2. 'this' in struct is not a pointer, but an instance

I was writing a struct and always writing '*this'
bothered me a little bit.  And I think assuming 'this' to be
an instance in struct is a very straightforward way of
thinking in D's policy.  I hope this isn't too late to
be changed.



3. assert(Object) checks null-ness, assert(Object.invariant) checks contract

Since 'if (Object)' checks if it is null or not, I thought
it is not so reasonable to make assert(Object) check its
invariability.  In the proposed way, the code also has clarity
in its meanings.



4. /+ +/ comments out, /++ +/ uncomments

While debugging with nested comments, I realized that I always
had to remember where to comment out so that I could make things
back.  Letting /++ +/ make the code inside valid again would be
a very good way to solve this problem and make D's nested comment
more comparable to the '#if 0 ... #endif' stuff in C/C++.



5. .init propery of function arguments

It seems like .init property of function arguments is currently
same with <its type>.init, i.e.,

void foo(int x)
{
assert(x.init == int.init);
}

So, why not make the .init property return the value passed when the
function was called.  This could be used as the 'const-ness' check of
the arguments, like

void foo(int x)
out {
assert(x == x.init);	// confirm the value never been changed
}
body {
/* do nothing */
}



6. special scope rules in contract

While in & out contract is *very* useful for developing (I proved
myself! ;)), I think there is still some more things improvable.
One thing I believe would be very useful is to allow more flexible
scope rules, such as,

'in' scope inherited by 'body' and 'out',
'body' scope inherited by 'out'.

Then you can declare variables only for contract checking.
For example, you can simulate the 'const-ness' check in this way too.

void foo(int x)
in {
int y = x;
}
out {
assert(y == x);		// able to access 'y'
}
body {
/* do nothing */
}



7. do-while scope rule (proposed before)

This is something proposed before in
http://www.digitalmars.com/d/archives/21339.html
and I really appreciated the idea.
I want it to be re-thought for one more chance.



P.S.
I love to hear opinions from anyone else, especially those
with experience in writing D, and of course, Walter !

-tetsuya
Dec 13 2004
next sibling parent reply Tyro <Tyro_member pathlink.com> writes:
In article <cpkagp$1s59$1 digitaldaemon.com>, tetsuya says...


[snip]

4. /+ +/ comments out, /++ +/ uncomments

While debugging with nested comments, I realized that I always
had to remember where to comment out so that I could make things
back.  Letting /++ +/ make the code inside valid again would be
a very good way to solve this problem and make D's nested comment
more comparable to the '#if 0 ... #endif' stuff in C/C++.


Oh, please don't do that. It is the single most confusing thing about learning
to program in C/C++. So much so that I have settled for simply learning
programming on my own by simply rummaging through D files. You don't know how
dumb I feel being one of the oldest followers of this language and not being
able to contribute to its development. It's like I'm reenventing the wheel, but
God knows it's far less confusing than Preprocessor Directives. Please don't
confuse me anymore than I already am.



[snip]

7. do-while scope rule (proposed before)

This is something proposed before in
http://www.digitalmars.com/d/archives/21339.html
and I really appreciated the idea.
I want it to be re-thought for one more chance.


I think this is a very handy feature to have in the language and
enthusiastically support its inclusion.


P.S.
I love to hear opinions from anyone else, especially those
with experience in writing D, and of course, Walter !

-tetsuya


P.S.
The most important feature in my mind is the Book that teaches me to progam. I
obviously don't know how to ask the right questions so I can only hope for the
book that will teach me to become a programmer using the D language.

Andrew
--
acedwards at ieee dot org



 Dec 13 2004



  parent reply tetsuya <tetsuya_member pathlink.com>  writes:


In article <cpkklb$28g2$1 digitaldaemon.com>, Tyro says...

In article <cpkagp$1s59$1 digitaldaemon.com>, tetsuya says...


[snip]

4. /+ +/ comments out, /++ +/ uncomments

While debugging with nested comments, I realized that I always
had to remember where to comment out so that I could make things
back.  Letting /++ +/ make the code inside valid again would be
a very good way to solve this problem and make D's nested comment
more comparable to the '#if 0 ... #endif' stuff in C/C++.


Oh, please don't do that. It is the single most confusing thing about learning
to program in C/C++. So much so that I have settled for simply learning
programming on my own by simply rummaging through D files. You don't know how
dumb I feel being one of the oldest followers of this language and not being
able to contribute to its development. It's like I'm reenventing the wheel, but
God knows it's far less confusing than Preprocessor Directives. Please don't
confuse me anymore than I already am.


I didn't mean to say preprocessor is superior than what D offers as
its alternatives.  I was just feeling that C's way (switching by
simply altering 0 or 1) is one of a few things where C is a little
more programmer-friendly.



[snip]

7. do-while scope rule (proposed before)

This is something proposed before in
http://www.digitalmars.com/d/archives/21339.html
and I really appreciated the idea.
I want it to be re-thought for one more chance.


I think this is a very handy feature to have in the language and
enthusiastically support its inclusion.


P.S.
I love to hear opinions from anyone else, especially those
with experience in writing D, and of course, Walter !

-tetsuya


P.S.
The most important feature in my mind is the Book that teaches me to progam. I
obviously don't know how to ask the right questions so I can only hope for the
book that will teach me to become a programmer using the D language.


Fair enough.  I hope I could someday (hopefully in the near future)
write a site about D and contribute to make D community bigger ;)
But it doesn't mean no more features should be considered or added,
I guess.


Andrew
--
acedwards at ieee dot org


P.S.
You sound like you're little aggressive, but what's your problem?
If I did something impolite then please just tell me about it, or
just simply forgive me because English is not my first language.

And I don't mean to confuse you, I mean to want D to be a great
language,
or even greater than it is now.  If you are confused by what I
said, then just ignore it because if some (or all) of my ideas
would seem stupid to the crowds then they would not be adopted in
any of the future spec.  I also want no idea to be employed if it
makes things more confusing.

cheers,
-tetsuya



 Dec 13 2004



  parent  "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com>  writes:


 I didn't mean to say preprocessor is superior than what D offers as
 its alternatives.  I was just feeling that C's way (switching by
 simply altering 0 or 1) is one of a few things where C is a little
 more programmer-friendly.


Maybe you can use if(1) and if(0), or version(any) and version(none) 
instead?

L. 



 Dec 13 2004



prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


tetsuya wrote:


 4. /+ +/ comments out, /++ +/ uncomments
 
 While debugging with nested comments, I realized that I always
 had to remember where to comment out so that I could make things
 back.  Letting /++ +/ make the code inside valid again would be
 a very good way to solve this problem and make D's nested comment
 more comparable to the '#if 0 ... #endif' stuff in C/C++.


You should not use comments to disable code,
instead you could use either "debug { }", or
version(none) or version(all) for #if 0 or 1...

/+ +/ isn't used for much else than commenting
out code, that had been commented with /* */

--anders



 Dec 13 2004



  parent reply tetsuya <tetsuya_member pathlink.com>  writes:


In article <cpkm0l$29rc$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

tetsuya wrote:


 4. /+ +/ comments out, /++ +/ uncomments
 
 While debugging with nested comments, I realized that I always
 had to remember where to comment out so that I could make things
 back.  Letting /++ +/ make the code inside valid again would be
 a very good way to solve this problem and make D's nested comment
 more comparable to the '#if 0 ... #endif' stuff in C/C++.


You should not use comments to disable code,
instead you could use either "debug { }", or
version(none) or version(all) for #if 0 or 1...

/+ +/ isn't used for much else than commenting
out code, that had been commented with /* */

--anders


Thanks for the suggestion.  I'll take that.

But then what are nested comments used for?
Seems like there's not so much need for it.

-tetsuya



 Dec 13 2004



  parent reply J C Calvarese <jcc7 cox.net>  writes:


tetsuya wrote:

 In article <cpkm0l$29rc$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
 

tetsuya wrote:



4. /+ +/ comments out, /++ +/ uncomments

While debugging with nested comments, I realized that I always
had to remember where to comment out so that I could make things
back.  Letting /++ +/ make the code inside valid again would be
a very good way to solve this problem and make D's nested comment
more comparable to the '#if 0 ... #endif' stuff in C/C++.






I don't quite understand what you're suggesting, but I like the way that 
nested comments currently work. I don't see a need for improving it, but 
  maybe that's just because I haven't run into the problem you're trying 
to solve.


You should not use comments to disable code,
instead you could use either "debug { }", or
version(none) or version(all) for #if 0 or 1...

/+ +/ isn't used for much else than commenting
out code, that had been commented with /* */

--anders




I agree with that.


 Thanks for the suggestion.  I'll take that.
 
 But then what are nested comments used for?
 Seems like there's not so much need for it.
 
 -tetsuya


True, they aren't right for every situation, but nested comments have 
come in very handy for me when I'm trying to nail down a bug. If 
something weird is happening (but I'm not sure where the problem is), I 
might used nested comments to comment out a large section. If I still 
see the problem, I can enlarge the commented section again by nesting 
the first commented area and adding another section. Take my word for 
it, they are useful the way they currently work.

In my mind, the nested comments should be removed from code once the 
bugs are fixed. If the contained code isn't needed anymore, then it 
should be removed altogether of course.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Dec 13 2004



  parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J C Calvarese schrieb am Mon, 13 Dec 2004 17:39:29 -0600:

 In my mind, the nested comments should be removed from code once the 
 bugs are fixed. If the contained code isn't needed anymore, then it 
 should be removed altogether of course.


How about using version(none){} ? ...

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFBviyD3w+/yD4P9tIRAqhCAKCLKgPmAZKeMmtK5OUHE2uPvUnA2wCbB5ak
b9QYV1FKnTp4f4xB3N3hRwc=
=gfml
-----END PGP SIGNATURE-----



 Dec 13 2004



  parent  J C Calvarese <jcc7 cox.net>  writes:


Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 J C Calvarese schrieb am Mon, 13 Dec 2004 17:39:29 -0600:
 

In my mind, the nested comments should be removed from code once the 
bugs are fixed. If the contained code isn't needed anymore, then it 
should be removed altogether of course.


 
 
 How about using version(none){} ? ...
 
 Thomas


I was referring to code that has outlived its usefulness or that was 
worthless to begin with. I'd assume that version(none){} would be 
reserved for code that might be useful. Each tool has its purpose. More 
tools are better than fewer tools.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Dec 13 2004



prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com>  writes:


"tetsuya" <tetsuya_member pathlink.com> wrote in message
news:cpkagp$1s59$1 digitaldaemon.com...

 D has been a great language :)
 But I dare try to give some proposals that I though might be
 useful from the experience of writing about 2500 lines in D
 so far.  Please think about them for a little bit ;))


 1. auto-calculation of static array length

 Since declaring like

 int[] a = [1, 2];

 gives a dynamic array, I though maybe letting

 int[const] a = [1, 2];

 be a static array would make enough sense.


nice idea but the trouble is finding a nice keyword to use. The choice of
"const" seems reasonable but it isn't clear from the code what is going on.
To a newbie it would probably look pretty confusing.


 2. 'this' in struct is not a pointer, but an instance

 I was writing a struct and always writing '*this'
 bothered me a little bit.  And I think assuming 'this' to be
 an instance in struct is a very straightforward way of
 thinking in D's policy.  I hope this isn't too late to
 be changed.


Can you give examples of when you needed to write *this? I've found most
struct uses of "this" in structs are to get at members and in that case
this.foo works fine IIRC.

[snip]


 4. /+ +/ comments out, /++ +/ uncomments

 While debugging with nested comments, I realized that I always
 had to remember where to comment out so that I could make things
 back.  Letting /++ +/ make the code inside valid again would be
 a very good way to solve this problem and make D's nested comment
 more comparable to the '#if 0 ... #endif' stuff in C/C++.


seems confusing

[snip]


 6. special scope rules in contract

 While in & out contract is *very* useful for developing (I proved
 myself! ;)), I think there is still some more things improvable.
 One thing I believe would be very useful is to allow more flexible
 scope rules, such as,

 'in' scope inherited by 'body' and 'out',
 'body' scope inherited by 'out'.

 Then you can declare variables only for contract checking.
 For example, you can simulate the 'const-ness' check in this way too.

 void foo(int x)
 in {
 int y = x;
 }
 out {
 assert(y == x); // able to access 'y'
 }
 body {
 /* do nothing */
 }


that sounds cool!

[snip]



 Dec 13 2004



  parent  tetsuya <tetsuya_member pathlink.com>  writes:


In article <cpkq10$2erj$1 digitaldaemon.com>, Ben Hinkle says...

[snip]

 2. 'this' in struct is not a pointer, but an instance

 I was writing a struct and always writing '*this'
 bothered me a little bit.  And I think assuming 'this' to be
 an instance in struct is a very straightforward way of
 thinking in D's policy.  I hope this isn't too late to
 be changed.


Can you give examples of when you needed to write *this? I've found most
struct uses of "this" in structs are to get at members and in that case
this.foo works fine IIRC.


I was making a structure that represents a rational number
(I don't do it in class becaues rational number is to be
numerically operated many times and I wanted speed.) and
I wonder how many times I wrote "return '*this;'.

Anyway, I think even if there's not much time everyone has
to write '*this', it should be modified to make sense.
As you know, one has to be able to write most (or IMHO all)
of the code *without* using pointers when he dare chose D.
I believe it is one of the biggest and important challenge
of D while it is still pursuing equivalent to or even more
speed than C/C++.


[snip]

 6. special scope rules in contract

 While in & out contract is *very* useful for developing (I proved
 myself! ;)), I think there is still some more things improvable.
 One thing I believe would be very useful is to allow more flexible
 scope rules, such as,

 'in' scope inherited by 'body' and 'out',
 'body' scope inherited by 'out'.

 Then you can declare variables only for contract checking.
 For example, you can simulate the 'const-ness' check in this way too.

 void foo(int x)
 in {
 int y = x;
 }
 out {
 assert(y == x); // able to access 'y'
 }
 body {
 /* do nothing */
 }


that sounds cool!


Yeah! :))
I often feel desperate when I try to write reasonable
yet efficient contracts.


[snip]


-tetsuya



 Dec 13 2004



prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


tetsuya wrote:


 1. auto-calculation of static array length
 
 Since declaring like
 
 int[] a = [1, 2];
 
 gives a dynamic array, I though maybe letting
 
 int[const] a = [1, 2];
 
 be a static array would make enough sense.


Remember that the static arrays in D are just
like "regular" arrays in C. That is, pointers.

static int* a = [1, 2]; // C: int a[] = {1, 2};

(for some reason, all such arrays need to be static to be inited:
"variable a is not a static and cannot have static initializer")

Usually you *want* to type them, though...
"int[2] a = [1, 2];" is more "type-safe" ?


Something like the following (D) code:


 import std.stdio;
 void main()
 {
   // D style
   static int[] a = [1, 2];
   foreach (int i; a) writefln("%d",i);
 
   // C style
   static int *b = [1, 2, -1];
   for (int* p = b; *p != -1; p++) printf("%d\n",*p);
 }


Most people prefer the dynamic arrays. :-)

--anders

PS.
The "-1" is known as a sentinel. Like the '\0' in strings ?
One could have used a length. Or in C: sizeof(a)/sizeof(a[0])



 Dec 13 2004



  parent reply tetsuya <tetsuya_member pathlink.com>  writes:


In article <cpl091$2mhq$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...


[snip]

Remember that the static arrays in D are just
like "regular" arrays in C. That is, pointers.

static int* a = [1, 2]; // C: int a[] = {1, 2};


By "static array" I mean "static array" as opposed to "dynamic array"
whose length is known at compile time.  Its "static" has nothing to
do with heap area / stack area. I guess you're taking me wrong?
Please see,
http://www.digitalmars.com/d/arrays.html


[snip]


Usually you *want* to type them, though...


I don't think so.  Everytime you need a big or small "static" array,
you want to let your compiler handle the length to make code easier
to be modified and read.
That is one of the reasons you think out a trick like
sizeof(a)/sizeof(a[0]) in C.  You never want to calculate the length
of an array yourself, let alone write it (what you call magic number)
down on your own code.



"int[2] a = [1, 2];" is more "type-safe" ?


Please tell me how safe it is :-Q  IMHO, "type-safe" is not about
specifying int[2] or int[5], but hiding those magic numbers.


[snip]


Most people prefer the dynamic arrays. :-)

--anders


Surely you don't include me then.. Please don't ban me from the
D community for my uniqueness, or stupidness.. :)

-tetsuya



 Dec 13 2004



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


tetsuya wrote:


 By "static array" I mean "static array" as opposed to "dynamic array"
 whose length is known at compile time.  Its "static" has nothing to
 do with heap area / stack area. I guess you're taking me wrong?


Not really, but maybe I explained my little "workaround" badly...
(and while it does work, it might be considered a "gross hack")


"int[2] a = [1, 2];" is more "type-safe" ?


 
 Please tell me how safe it is :-Q  IMHO, "type-safe" is not about
 specifying int[2] or int[5], but hiding those magic numbers.


Just meant that you can't interchange it with an int[5] array...
(and you are right that the numbers should probably be const's)


Most people prefer the dynamic arrays. :-)


 
 Surely you don't include me then.. Please don't ban me from the
 D community for my uniqueness, or stupidness.. :)


Oh, I hadn't planned to :-) What you suggest is *not* unique, and
does involve a lot less overhead than dynamic array + GC and all.

It's not a bad idea at all, for an add-on.

Just that it needs some new declaration style, since [] is "taken".
I guess your "[const]" isn't that bad, but looks a little like AA?

Maybe something like "[...]" could work ?


Inits of arrays, especially static arrays and associative arrays,
isn't really complete yet - so all suggestions will improve them...

--anders



 Dec 13 2004



prev sibling next sibling parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


"tetsuya" <tetsuya_member pathlink.com> escribió en el mensaje 
news:cpkagp$1s59$1 digitaldaemon.com...
|
| 3. assert(Object) checks null-ness, assert(Object.invariant) checks contract
|
| Since 'if (Object)' checks if it is null or not, I thought
| it is not so reasonable to make assert(Object) check its
| invariability.  In the proposed way, the code also has clarity
| in its meanings.
|

You can always do "assert(Object !== null);"

|
|
| 4. /+ +/ comments out, /++ +/ uncomments
|
| While debugging with nested comments, I realized that I always
| had to remember where to comment out so that I could make things
| back.  Letting /++ +/ make the code inside valid again would be
| a very good way to solve this problem and make D's nested comment
| more comparable to the '#if 0 ... #endif' stuff in C/C++.
|
|

I use them. Here's what I do to uncomment:

//+
...code...
//+/

Remove the first slash to comment, add it to uncomment.

-----------------------
Carlos Santander Bernal 



 Dec 13 2004



  parent reply tetsuya <tetsuya_member pathlink.com>  writes:


In article <cplfsf$5mu$1 digitaldaemon.com>, Carlos Santander B. says...

"tetsuya" <tetsuya_member pathlink.com> escribió en el mensaje 
news:cpkagp$1s59$1 digitaldaemon.com...
|
| 3. assert(Object) checks null-ness, assert(Object.invariant) checks contract
|
| Since 'if (Object)' checks if it is null or not, I thought
| it is not so reasonable to make assert(Object) check its
| invariability.  In the proposed way, the code also has clarity
| in its meanings.
|

You can always do "assert(Object !== null);"


IIRC, there's no operation !== in D, instead
"assert(! (Object is null));" will do the job.

But what I meant was not wether it can be done in current
spec, but treating the expression in 'assert' as
different from that in 'if' and others would be somehow
confusing because both are dealing with conditions, or
booleans.


|
|
| 4. /+ +/ comments out, /++ +/ uncomments
|
| While debugging with nested comments, I realized that I always
| had to remember where to comment out so that I could make things
| back.  Letting /++ +/ make the code inside valid again would be
| a very good way to solve this problem and make D's nested comment
| more comparable to the '#if 0 ... #endif' stuff in C/C++.
|
|

I use them. Here's what I do to uncomment:

//+
...code...
//+/

Remove the first slash to comment, add it to uncomment.

-----------------------
Carlos Santander Bernal 


Thanks.  I just suggested because I never knew version(none)
and version(all) could be used to comment codes.  Now I will
use that.  I admit that it wasn't a good idea, just forget it.

 To all those who are threatened by that idea




I'm done with nested comment stuff now :)

-tetsuya



 Dec 13 2004



  parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


"tetsuya" <tetsuya_member pathlink.com> escribió en el mensaje 
news:cpln80$d07$1 digitaldaemon.com...
| IIRC, there's no operation !== in D, instead
| "assert(! (Object is null));" will do the job.
|

Err...

void main ()
{
    Object o = new Object;
    assert ( o !== null );
}

Compiles, links and run.

-----------------------
Carlos Santander Bernal 



 Dec 13 2004



  parent  tetsuya <tetsuya_member pathlink.com>  writes:


In article <cplp97$f65$1 digitaldaemon.com>, Carlos Santander B. says...

"tetsuya" <tetsuya_member pathlink.com> escribió en el mensaje 
news:cpln80$d07$1 digitaldaemon.com...
| IIRC, there's no operation !== in D, instead
| "assert(! (Object is null));" will do the job.
|

Err...

void main ()
{
    Object o = new Object;
    assert ( o !== null );
}

Compiles, links and run.


Ouch!!! Sorry about that. I'm embarraseed..
I should have tested before posting.

There might be some more things I can't just reason from the
documents..
Gotta be care > myself.


-----------------------
Carlos Santander Bernal 





 Dec 13 2004



prev sibling  parent reply "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com>  writes:


Hi.. Just a quicky.


 1. auto-calculation of static array length
 [...]


I agree, but not by using 'const'. Why not make it a constant-length array 
instead of a dynamic one? Or maybe use "..." for, as in "int[...] a" or 
"int[] a = [1,2,...];"  :-S


 2. 'this' in struct is not a pointer, but an instance
 [...]


I agree that 'this' in D should behave like C++'s '*this'. If some pro wants 
the pointer, he can always do '&this'.


 3. assert(Object) checks null-ness, assert(Object.invariant) checks 
 contract
 [...]


I agree with you.


 4. /+ +/ comments out, /++ +/ uncomments
 [...]


Confusing.


 5. .init propery of function arguments
 [...]


Making <instance>.init different from <type>.init seems too big a change, 
since .init is something like a static property of a class.


 6. special scope rules in contract
 [...]


Aren't the contracts compiled-in optionally? This would mean that if you 
don't want the contracts to be tested, the declaration in the in/out blocks 
should still be compiled, but not the statements? Odd.


 7. do-while scope rule (proposed before)
 [...]


Got my vote too!

L. 



 Dec 13 2004



  parent reply tetsuya <tetsuya_member pathlink.com>  writes:


In article <cpm4pt$ps7$1 digitaldaemon.com>, Lionello Lunesu says...

Hi.. Just a quicky.


 1. auto-calculation of static array length
 [...]


I agree, but not by using 'const'. Why not make it a constant-length array 
instead of a dynamic one? Or maybe use "..." for, as in "int[...] a" or 
"int[] a = [1,2,...];"  :-S


In fact, I don't care what the syntax's gonna be.
I just wanted the compiler's auto-calculation.
So let's leave to Walter what sugar to eat :)



 2. 'this' in struct is not a pointer, but an instance
 [...]


I agree that 'this' in D should behave like C++'s '*this'. If some pro wants 
the pointer, he can always do '&this'.


Exactly!


[snip]


 5. .init propery of function arguments
 [...]


Making <instance>.init different from <type>.init seems too big a change, 
since .init is something like a static property of a class.


Not actually ;)
'int.init' is assured to be 'cast(int) 0', but
'<variable_name>.init' is not.
For example, the test below shows the interesting behavior
of .init.

<code>
unittest
{
int x = 5;
assert(x.init == 5);
}

unittest
{
int x;
x = 5;
assert(x.init == int.init);
}
</code>



 6. special scope rules in contract
 [...]


Aren't the contracts compiled-in optionally? This would mean that if you 
don't want the contracts to be tested, the declaration in the in/out blocks 
should still be compiled, but not the statements? Odd.


Hmm, I guess I need an example to understand it well.



 7. do-while scope rule (proposed before)
 [...]


Got my vote too!

L. 



-tetsuya



 Dec 14 2004



  parent  Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no>  writes:


tetsuya wrote:

6. special scope rules in contract
[...]


Aren't the contracts compiled-in optionally? This would mean that if you 
don't want the contracts to be tested, the declaration in the in/out blocks 
should still be compiled, but not the statements? Odd.


 
 
 Hmm, I guess I need an example to understand it well.


The problem is that you say "'in' scope inherited by 'body' [...]". The 
spec says: "For a release build of the code, the in and out code is not 
inserted." So there is a conflict. I can't see what you would want to 
use the 'in' scope for in the 'body', and for the sake of efficiency I 
prefer the spec as it is now.

However, I do see the use for letting the scope of 'out' inherit the 
scope of 'in', which would allow your example. You have my vote on this 
one :-)

As for letting 'out' inherit the 'body' scope, I do not agree. The 'out' 
contract should verify that the function implementation ('body') does 
the right thing. For correctness, it is important that changes in the 
implementation can not change the contract, i.e., the test should be 
independent from the thing that is being tested. So the 'out' block 
should not have access to implementation details of the function, 
therefore I do not want 'out' to inherit the 'body' scope.

Cheers,
Bastiaan.



 Dec 14 2004