In article <ddg4qi$o6l$1@digitaldaemon.com>, AJG says...
>
>Hi,
>
>>The array declaration syntax is fine. I don't think we need to do anything to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of related concepts like readonly, const, final etc but those are different (and much larger) topics.
>
>Ok, so you say nothing needs to be done about static arrays? I beg to differ. I think the current terminology and keywords are confusing and should be revised.
>
>As it stands, what's the difference between, and how to you describe the following:
>
># void Foo() {
>#    static int[] A;
>#    static int[5] B;
>#    int[]  D
>#    int[5] C;
># }
>
>It would make more sense to me to call:
>
>'A' a shared, dynamic array.
>'B' a shared, static array.
>'C' a local, dynamic array.
>'D' a local, static array.
>
>As it stands, 'B' is a 'static, static' array, right? Doesn't that merit change?
>
>>> Ah, the problem is this thread is not exclusively about static and dynamic
>>> arrays. It's about the terms static and dynamic in general. I think
>>> constants
>>> are very much related, and I think complete solution would take into
>>> account
>>> both static and const at once.
>>
>>True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.
>
>I'd say you are right about dynamic. It's not in code and it's fairly well understood. So I agree it's not much of an issue. But I disagree about static.
>
>I don't like how the two meanings of static (shared and compile-time) are merged into one. Particularly when the two can collide in one object. Why not disambiguate and introduce 'shared'?
>
>>> IMHO the problem stems from trying to remain pseudo-compatible with C, and
>>> from
>>> trying to save keywords by mixing storage classes with type attributes.
>>
>>Actually "static" in C is overloaded when used for toplevel symbols to mean what D uses "private" for. So I'd say that D breaks from C for exactly the reason you mention.
>
>So what do the following mean, then?
>
># static private void main() {}
># static  void main() {}
># private void main() {}
># void main() {}
>
>Is there a difference?
>
>Cheers,
>--AJG.


I fully agree with you AJG,

static where it means compile-time should stay the same.  static where it means shared should change to shared, like in java, and C#.

static int[5] foo; would become:

shared int[5] foo;

static assert(is(foo == int[5])) would stay the same.

"AJG" <AJG_member@pathlink.com> wrote in message news:ddg4qi$o6l$1@digitaldaemon.com...
> Hi,
>
>>The array declaration syntax is fine. I don't think we need to do anything
>>to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots
>>of
>>related concepts like readonly, const, final etc but those are different
>>(and much larger) topics.
>
> Ok, so you say nothing needs to be done about static arrays? I beg to
> differ. I
> think the current terminology and keywords are confusing and should be
> revised.
>
> As it stands, what's the difference between, and how to you describe the following:
>
> # void Foo() {
> #    static int[] A;
> #    static int[5] B;
> #    int[]  D
> #    int[5] C;
> # }
>
> It would make more sense to me to call:
>
> 'A' a shared, dynamic array.
> 'B' a shared, static array.
> 'C' a local, dynamic array.
> 'D' a local, static array.
>
> As it stands, 'B' is a 'static, static' array, right? Doesn't that merit change?

I agree the concept we currently call a "static array" should be renamed. That's been the position of all the replies to this thread, from what I can tell. The part I disagree with you about is that the use of 'static' in the code to mean "static variable" needs to change. I think it's fine.

>>> Ah, the problem is this thread is not exclusively about static and
>>> dynamic
>>> arrays. It's about the terms static and dynamic in general. I think
>>> constants
>>> are very much related, and I think complete solution would take into
>>> account
>>> both static and const at once.
>>
>>True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.
>
> I'd say you are right about dynamic. It's not in code and it's fairly well understood. So I agree it's not much of an issue. But I disagree about static.
>
> I don't like how the two meanings of static (shared and compile-time) are
> merged
> into one. Particularly when the two can collide in one object. Why not
> disambiguate and introduce 'shared'?

Assuming the name "static array" is changed where does "static" mean "compile time"? Do you mean something like performing "static analysis" of a program? I think the meanings of static as it appears in code is pretty consitent and matches what one would expect from C/Java/C++ etc. I don't think introducing a new keyword is worth it.

>>> IMHO the problem stems from trying to remain pseudo-compatible with C,
>>> and
>>> from
>>> trying to save keywords by mixing storage classes with type attributes.
>>
>>Actually "static" in C is overloaded when used for toplevel symbols to
>>mean
>>what D uses "private" for. So I'd say that D breaks from C for exactly the
>>reason you mention.
>
> So what do the following mean, then?
>
> # static private void main() {}
> # static  void main() {}
> # private void main() {}
> # void main() {}
>
> Is there a difference?

If you read the doc it explains how static behaves http://www.digitalmars.com/d/attribute.html (read the "Static Attribute" section). In your case above it says the "static" is ignored (assuming main() is a top-level function). The private or lack of private has the usual meaning (read the "Protection Attribute" section of that same page).

> Cheers,
> --AJG.
>
> 

Hi,

>I agree the concept we currently call a "static array" should be renamed. That's been the position of all the replies to this thread, from what I can tell. The part I disagree with you about is that the use of 'static' in the code to mean "static variable" needs to change. I think it's fine.

A "static variable" makes no sense. Think about it. It's the same as a "constant variable". It's an oxymoron. What you mean to say is a "shared variable."

It applies a little differently to arrays. A "static array" (e.g. int[5] A) is closer to the "compile-time" meaning of static. It means the array itself has been evaluated at compile time. Therefore the array itself can not change at runtime.

int[5] a = new int[5]; // IIRC, error.

So in other words, a static array is the opposite of a dynamic array. Dynamic we established to mean variable at runtime. Therefore, logically a static array is not variable at runtime, which effectively means compile-time. So a "static array," while not exactly a marvelous term, is much better than a "static variable," which is a total contradiction.

If you want to fix "static arrays" as well, then you need (surprise!) yet another keyword. You suggested 'nonresizable', I suggested 'fixed'. Either one would be an improvement.

# /* dynamic length */ int[]  Dynamic = new int[5];
#   fixed /* length */ int[5] Fixed;

>> I don't like how the two meanings of static (shared and compile-time) are
>> merged
>> into one. Particularly when the two can collide in one object. Why not
>> disambiguate and introduce 'shared'?
>
>Assuming the name "static array" is changed where does "static" mean "compile time"? Do you mean something like performing "static analysis" of a program?

Well, a static assert fails at compile-time... doesn't it?

The strongest meaning of static is compile-time. Static analysis, static if, static assert, etc...

So, a "static function," and a "static variable" aren't good terms.

>I think the meanings of static as it appears in code is pretty consitent

# static assert/if: compile-time.
# static function/var/class: shared at runtime.

That's not consistent at all.

>matches what one would expect from C/Java/C++ etc.

One would expect C top-level 'static' to remain so, not 'private'. That doesn't match. So then you could argue "well, it _mostly_ matches," but then that's arbitrary and means little. D already broke with C on static. Let's take it all the way and improve it once and for all.

>I don't think introducing a new keyword is worth it.

Again with the keyword stinginess. What if instead of keywords they were made special attributes?

# [shared] int Foo() {
#     [shared] int counter = 0;
#     string shared = "shared";
#     return (counter++);
# }

>> So what do the following mean, then?
>> # static private void main() {}
>> # static  void main() {}
>> # private void main() {}
>> # void main() {}
>>
>> Is there a difference?
>
>If you read the doc it explains how static behaves http://www.digitalmars.com/d/attribute.html (read the "Static Attribute" section). In your case above it says the "static" is ignored (assuming main() is a top-level function). The private or lack of private has the usual meaning (read the "Protection Attribute" section of that same page).

Ah, I see. Yet another reason to at least issue a warning when attributes are ignored nonchalantly. Oh well...

Thanks,
--AJG.

Hi,

>I fully agree with you AJG,

Yay! (Don't let them know I paid you ;)

>static where it means compile-time should stay the same.  static where it means shared should change to shared, like in java, and C#.
>
>static int[5] foo; would become:
>
>shared int[5] foo;
>
>static assert(is(foo == int[5])) would stay the same.

Yep, that's exactly right. That'd be ideal.

Cheers,
--AJG.

In article <ddg5h4$oqi$1@digitaldaemon.com>, Shammah Chancellor says...
>
>I fully agree with you AJG,
>
>static where it means compile-time should stay the same.  static where it means shared should change to shared, like in java, and C#.
>

Uhm, no - not like in Java and C#. It's static there too. Another reason to stick with "static" IMO. You perhaps meant VB.NET ...

Best regards,
Stefan

In article <ddfl3d$53b$1@digitaldaemon.com>, Ben Hinkle says...
>
>The array declaration syntax is fine. I don't think we need to do anything to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of related concepts like readonly, const, final etc but those are different (and much larger) topics.
>
> ....
>True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.

I fully agree with Ben here. We (and the doc) should change our wording since "static" is way too overloaded for informal communication, but I know what it means when I see it in code (and the same holds for programmers that come from Java or C#).

Just my 2c,
Stefan

Hi,

> A "static variable" makes no sense. Think about it. It's the same as a "constant
> variable". It's an oxymoron. What you mean to say is a "shared variable."

Sorry to barge in, but I beg to differ. From a dictionary: static -- having no motion, fixed, stationary, etc. A static variable is just that - its memory location is fixed at compile time, so imho a "static variable" uses the word static in the best way :)


> It applies a little differently to arrays. A "static array" (e.g. int[5] A) is
> closer to the "compile-time" meaning of static. It means the array itself has
> been evaluated at compile time. Therefore the array itself can not change at
> runtime.

Well, in the case of arrays the static/dynamic refers to both length and memory location, although not in quite the same sense wrt the location as above (it's on the stack vs. heap). I'm fine with static arrays, too..


> If you want to fix "static arrays" as well, then you need (surprise!) yet
> another keyword. You suggested 'nonresizable', I suggested 'fixed'. Either one
> would be an improvement.
> 
> # /* dynamic length */ int[]  Dynamic = new int[5];
> #   fixed /* length */ int[5] Fixed;

Why exactly would you require 'fixed' there? It's static/fixed even without it?


> # static assert/if: compile-time.
> # static function/var/class: shared at runtime.
> 
> That's not consistent at all.

It is consistent, at least a bit - in all cases, the outcome doesn't depend on runtime:

static assert's success doesn't depend on runtime (and in the case it always failed, the program would be quite useless, so the compiler refuses to even compile it)

static if's outcome also doesn't depend on runtime, so the compiler can choose one version or another already at compile time..

static variables' location is fixed at compile time

static arrays' length is fixed at compile time

static functions don't depend on runtime instances of a class

static classes don't (automatically) depend on runtime instances of their outer classes


>>matches what one would expect from C/Java/C++ etc.
> 
> One would expect C top-level 'static' to remain so, not 'private'. That doesn't
> match. So then you could argue "well, it _mostly_ matches," but then that's
> arbitrary and means little. D already broke with C on static. Let's take it all
> the way and improve it once and for all.

Well, in Java the meaning of static vars, funcs and classes is exactly the same as in D, which I think is a plus and I definitely wouldn't like to see it changed..


xs0

On Thu, 11 Aug 2005 09:50:36 -0400, Ben Hinkle wrote:


[snip]

> 
> True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code.

Yes. I was only referring to the ambiguous usage of these words in conversations. I was not advocating change in D or even advocating that D should not be changed. I was not talking about the D syntax at all.

-- 
Derek Parnell
Melbourne, Australia
12/08/2005 8:13:51 AM

xs0 schrieb:

> Thomas Kühne wrote:
> 
>>
>> # The const attribute declares constants that can be evaluated at # compile time.
>>
>> # A const declaration without an initializer must be initialized in a
>> # constructor (for class fields) or in a static constructor (for static
>> # class members, or module variable declarations).
> 
> 
> I saw that too, but this also works:
> 
> import std.stdio;
> 
> int counter=0;
> 
> int qwe()
> {
>     return counter++;
> }
> 
> class Foo
> {
>     const int bar;
>     public this()
>     {
>         bar=qwe();
>     }
> }
> 
> void main()
> {
>     for (int a=0; a<10; a++) {
>         Foo foo=new Foo();
>         writefln(foo.bar);
>     }
> }
> 
> So I guess it's no longer compile-time only?

Added to DStress as http://dstress.kuehne.cn/undefined/const_24.d

Thomas