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

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

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

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

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

"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]

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

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])

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

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