Hi,

In article <dddmrp$rvf$1@digitaldaemon.com>, Ben Hinkle says...
>
>> But how about the concept itself: That there are, and that we should have
>> at our
>> disposal, two distincts things:
>>
>> 1) A compile time, constant-foldable, declaration.
>> 2) A run-time, dynamically set (once), neverchanging, readonly
>> declaration.
>>
>IMHO the current syntax is fine.

Fine, as in... not broken? Yes, then it's more or less fine. Doesn't it leave room for improvement, though?

For instance, the second case I talked about is not supported. Why?

Say I want to create a _constant_ value, it will not change throughout its life, but I want to set this value at runtime. Does the current syntax support that? No.

In C# there's a similar "readonly" keyword, but it's not exactly what I mean.

Would you be opposed to something like the following?
(If yes, then what's the alternative)?

# const int foo = rand();
# foo = 5; // error.

Make no mistake, foo is a _constant_ by all definitions, except it's not a compile time one. So, my gut tells me overloading const (the current syntax) yet again is not the best idea ;), which is why I proposed "fixed."

Cheers,
--AJG.

AJG wrote:

> Make no mistake, foo is a _constant_ by all definitions, except it's not a
> compile time one. So, my gut tells me overloading const (the current syntax) yet
> again is not the best idea ;), which is why I proposed "fixed."

final might also not be a bad idea, especially because it's already a keyword and works in exactly the way you describe in Java. OTOH, DMD 0.129 allows this:

import std.stdio;

class Foo
{
	const int bar;
	public this()
	{
		bar=5;
	}
}

void main()
{
	Foo foo=new Foo();
	writefln(foo.bar);
}

Looking at DMD source changes, it would seem that initializing constants in constructors has silently been allowed :)


xs0

"AJG" <AJG_member@pathlink.com> wrote in message news:dddpdh$v7r$1@digitaldaemon.com...
> Hi,
>
> In article <dddmrp$rvf$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>> But how about the concept itself: That there are, and that we should
>>> have
>>> at our
>>> disposal, two distincts things:
>>>
>>> 1) A compile time, constant-foldable, declaration.
>>> 2) A run-time, dynamically set (once), neverchanging, readonly
>>> declaration.
>>>
>>IMHO the current syntax is fine.
>
> Fine, as in... not broken? Yes, then it's more or less fine. Doesn't it leave room for improvement, though?
>
> For instance, the second case I talked about is not supported. Why?

Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly). You might want to start a new thread about your proposal in order to keep it distinct from this one about how to document and talk about dynamic and static arrays.

> Say I want to create a _constant_ value, it will not change throughout its
> life,
> but I want to set this value at runtime. Does the current syntax support
> that?
> No.
>
> In C# there's a similar "readonly" keyword, but it's not exactly what I mean.
>
> Would you be opposed to something like the following?
> (If yes, then what's the alternative)?
>
> # const int foo = rand();
> # foo = 5; // error.
>
> Make no mistake, foo is a _constant_ by all definitions, except it's not a
> compile time one. So, my gut tells me overloading const (the current
> syntax) yet
> again is not the best idea ;), which is why I proposed "fixed."
>
> Cheers,
> --AJG.
>
> 

Hi,

>> For instance, the second case I talked about is not supported. Why?
>
>Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly).

Hm... perhaps I misunderstood you. If I may ask so, when you said "the syntax is fine," which parts were you referring to? This could clarify things.

>You might want to start a new thread about your proposal in order to keep it distinct from this one about how to document and talk about dynamic and static arrays.

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.

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.

Cheers,
--AJG.

Hi,

>This is just a general gripe, so you can dismiss it if you want.
>Is it just me, or are the terms 'static' and 'dynamic' a bit too overloaded
>in meaning.

As I said in another branch, I agree very much with this sentiment. My suggestion, meant to alleviate the burden a little, is the following:

What about replacing the class/function/var part of static with "shared"? I think it cleanly conveys what is meant, which is that all instances/functions share the same data.

Then static could be made to mean stricly "compile-time," as in static assert.

So you would have:

shared void main() {
shared int bar = 5;
static assert(0);
}

shared class Singleton {
shared void Foo(); // All good.
void Baz(); // Error: non-shared method in shared class.
}

That's a lot more intuitive to me than a "static class", specially when compared to a "static assert". You'd think a static class is only available at compile time or something.

Comments?

Cheers,
--AJG.

xs0 schrieb:
> AJG wrote:
> 
>> Make no mistake, foo is a _constant_ by all definitions, except it's
>> not a
>> compile time one. So, my gut tells me overloading const (the current
>> syntax) yet
>> again is not the best idea ;), which is why I proposed "fixed."
> 
> 
> final might also not be a bad idea, especially because it's already a keyword and works in exactly the way you describe in Java. OTOH, DMD 0.129 allows this:
> 
> import std.stdio;
> 
> class Foo
> {
>     const int bar;
>     public this()
>     {
>         bar=5;
>     }
> }
> 
> void main()
> {
>     Foo foo=new Foo();
>     writefln(foo.bar);
> }
> 
> Looking at DMD source changes, it would seem that initializing constants in constructors has silently been allowed :)

# 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).

Thomas

Thomas Kühne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> xs0 schrieb:
> 
>>AJG wrote:
>>
>>
>>>Make no mistake, foo is a _constant_ by all definitions, except it's
>>>not a
>>>compile time one. So, my gut tells me overloading const (the current
>>>syntax) yet
>>>again is not the best idea ;), which is why I proposed "fixed."
>>
>>
>>final might also not be a bad idea, especially because it's already a
>>keyword and works in exactly the way you describe in Java. OTOH, DMD
>>0.129 allows this:
>>
>>import std.stdio;
>>
>>class Foo
>>{
>>    const int bar;
>>    public this()
>>    {
>>        bar=5;
>>    }
>>}
>>
>>void main()
>>{
>>    Foo foo=new Foo();
>>    writefln(foo.bar);
>>}
>>
>>Looking at DMD source changes, it would seem that initializing constants
>>in constructors has silently been allowed :)
> 
> 
> # 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?


xs0

"AJG" <AJG_member@pathlink.com> wrote in message news:dddvke$18fr$1@digitaldaemon.com...
> Hi,
>
>>> For instance, the second case I talked about is not supported. Why?
>>
>>Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly).
>
> Hm... perhaps I misunderstood you. If I may ask so, when you said "the
> syntax is
> fine," which parts were you referring to? This could clarify things.

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.

>>You
>>might want to start a new thread about your proposal in order to keep it
>>distinct from this one about how to document and talk about dynamic and
>>static arrays.
>
> 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.

> 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.

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.

Hi,

>So I guess it's no longer compile-time only?

Is this true, or is the behaviour shown a weird parsing bug? Walter?

Cheers,
--AJG.