Alexander Panek wrote:
> Lutger wrote:
>> Xinok wrote:
>>> The problem with the const keyword is it doesn't guarantee the expression will
>>> be constant.
>>
>> It doesn't? How can you modify a const var then? (in D)
> 
> You can modify const variables that are not set directly at declaration (write-once constants) just by getting their address and modifying them through another variable/pointer.

Haha yes it works. Is that how it should be or is it a bug or compiler limitation? It looks whacky to me. You can only write a const once in a constructor or so says DMD, thus it seems like this subverts the system in more than one way. I can't imagine that ever being useful.

Tomas Lindquist Olsen wrote:
> Lutger wrote:
> 
>> Xinok wrote:
>>> The problem with the const keyword is it doesn't guarantee the
>>> expression will be constant.
>> It doesn't? How can you modify a const var then? (in D)
> 
> This actually feels more like a bug, but here's an example:
> 
> module noconst;
> import std.stdio;
> struct S {
>     float f;
> }
> const S s = {3.1415};
> void main() {
>     writefln(s.f);
>     s.f = 666;
>     writefln(s.f);
> }
> 
> (DMD.177)

Huh yes, const doesn't work at all for structs. This also compiles:

struct S
{
    const int i;
}

void main()
{
    S s;
    s.i = 10;
    s.i = 666;
}

Lutger wrote:
> Alexander Panek wrote:
>> Lutger wrote:
>>> Xinok wrote:
>>>> The problem with the const keyword is it doesn't guarantee the expression will
>>>> be constant.
>>>
>>> It doesn't? How can you modify a const var then? (in D)
>>
>> You can modify const variables that are not set directly at declaration (write-once constants) just by getting their address and modifying them through another variable/pointer.
> 
> Haha yes it works. Is that how it should be or is it a bug or compiler limitation? It looks whacky to me. You can only write a const once in a constructor or so says DMD, thus it seems like this subverts the system in more than one way. I can't imagine that ever being useful.

Why not?
It's useful when you work with sane programmers.

After all, with pointers and asm, there's no limit to how many things you can mess.

current:
void func(){}
alias func test;

suggestion:
void func(){}
alias test=func;

alias test2="test";

#this code is error yet
import std.typetuple,std.stdio;
void func(){writefln("test");}
alias TypeTuple!(func) test;
void main(){
  test[0]();//error
}
#And this too
import std.typetuple,std.stdio;
int x;
alias TypeTuple!(x*x) test;
void main(){
  x=10;
  writefln(test[0]);
  x=20;
  writefln(test[0]);
}

Hasan Aljudy wrote:
> 
> 
> Lutger wrote:
>> Alexander Panek wrote:
>>> Lutger wrote:
>>>> Xinok wrote:
>>>>> The problem with the const keyword is it doesn't guarantee the expression will
>>>>> be constant.
>>>>
>>>> It doesn't? How can you modify a const var then? (in D)
>>>
>>> You can modify const variables that are not set directly at declaration (write-once constants) just by getting their address and modifying them through another variable/pointer.
>>
>> Haha yes it works. Is that how it should be or is it a bug or compiler limitation? It looks whacky to me. You can only write a const once in a constructor or so says DMD, thus it seems like this subverts the system in more than one way. I can't imagine that ever being useful.
> 
> Why not?
> It's useful when you work with sane programmers.
> 
> After all, with pointers and asm, there's no limit to how many things you can mess.

Sure, if you want it you can break the type system. But there are some barriers for pointers, these are still typed. I don't think it is so obscure.
If you have a const value type in a class, you must set it in the initializer or the constructor. You also cannot modify it. Fine, but then if you have a getter return a reference to it, suddenly all bets are off.
This is not what I'd expect, probably because of a C++ bias I still have somewhere, that I (wrongly) think const is part of the type system?

Lutger wrote:
> Hasan Aljudy wrote:
>>
>>
>> Lutger wrote:
>>> Alexander Panek wrote:
>>>> Lutger wrote:
>>>>> Xinok wrote:
>>>>>> The problem with the const keyword is it doesn't guarantee the expression will
>>>>>> be constant.
>>>>>
>>>>> It doesn't? How can you modify a const var then? (in D)
>>>>
>>>> You can modify const variables that are not set directly at declaration (write-once constants) just by getting their address and modifying them through another variable/pointer.
>>>
>>> Haha yes it works. Is that how it should be or is it a bug or compiler limitation? It looks whacky to me. You can only write a const once in a constructor or so says DMD, thus it seems like this subverts the system in more than one way. I can't imagine that ever being useful.
>>
>> Why not?
>> It's useful when you work with sane programmers.
>>
>> After all, with pointers and asm, there's no limit to how many things you can mess.
> 
> Sure, if you want it you can break the type system. But there are some barriers for pointers, these are still typed. I don't think it is so obscure.
> If you have a const value type in a class, you must set it in the initializer or the constructor. You also cannot modify it. Fine, but then if you have a getter return a reference to it, suddenly all bets are off.
> This is not what I'd expect, probably because of a C++ bias I still have somewhere, that I (wrongly) think const is part of the type system?

The confusion comes from the way that D uses const in two ways.
const XXX = YYY;
really is const, cannot be changed (even in theory), and probably won't appear in the executable at all. This is definitely part of the type system.

const XXX;
is not const at all (it's a variable!). 'final' might have been a better name. As you mention, the read-only protection seems to be very fragile.
It seems a very hard thing to enforce.

Don Clugston wrote:
> The confusion comes from the way that D uses const in two ways.
> const XXX = YYY;
> really is const, cannot be changed (even in theory), and probably won't appear in the executable at all. This is definitely part of the type system.
> 
> const XXX;
> is not const at all (it's a variable!). 'final' might have been a better name. As you mention, the read-only protection seems to be very fragile.
> It seems a very hard thing to enforce.

Thank you for the clarification. This means that the original statement from the OP is not true:
"In D, the standard is to use 'const':
const int INT = 30;
The problem with the const keyword is it doesn't guarantee the expression will be constant."

Then the issue with consts (the first type) in structs and const structs must be a bug?

I was wrong btw about references to members, it only applies to structs not primitives.

Lutger wrote:
> Don Clugston wrote:
>> The confusion comes from the way that D uses const in two ways.
>> const XXX = YYY;
>> really is const, cannot be changed (even in theory), and probably won't appear in the executable at all. This is definitely part of the type system.
>>
>> const XXX;
>> is not const at all (it's a variable!). 'final' might have been a better name. As you mention, the read-only protection seems to be very fragile.
>> It seems a very hard thing to enforce.
> 
> Thank you for the clarification. This means that the original statement from the OP is not true:
> "In D, the standard is to use 'const':
> const int INT = 30;
> The problem with the const keyword is it doesn't guarantee the expression will be constant."

You are correct. The OP statement is untrue.
It's an important distinction -- if it's really a constant, you can use it inside a 'static if'. And you're not allowed to take the address of it.

> Then the issue with consts (the first type) in structs and const structs must be a bug?

I think so. There are a few quirks with array literals and apparently consts as well -- they look like compile-time constants, but AFAIK they are currently implemented as "read-only" variables.

> I was wrong btw about references to members, it only applies to structs not primitives.

Tomas Lindquist Olsen wrote:
> Lutger wrote:
> 
>> Xinok wrote:
>>> The problem with the const keyword is it doesn't guarantee the
>>> expression will be constant.
>> It doesn't? How can you modify a const var then? (in D)
> 
> This actually feels more like a bug, but here's an example:
> 
> module noconst;
> import std.stdio;
> struct S {
>     float f;
> }
> const S s = {3.1415};
> void main() {
>     writefln(s.f);
>     s.f = 666;
>     writefln(s.f);
> }
> 
> (DMD.177)

On Windows, DMD doesn't put constants into ROM.  I'm not entirely sure why, but I suspect it may be that the OS doesn't support the idea?


Sean

nazo wrote:
> Expressions! Expressions!  (/ ~.)/
> 
> I think that the exchange of parameters of alias is necessary from:
>   alias (x*2) exp;
> to:
>   alias exp=x*2;

I'm all for that.  Changing the order I mean, not necessarily aliases for expressions.  Typedef too.  They're all just saying symbol=value (where 'value' is a type).  But probably it will never change.  Alias is too closely connected to typedef, and typedef is too closely connected to C/C++ for Walter to change its syntax.  End result: neither will change.

> And I need alias arguments as syntax sugar like:
>   alias(alias i) exp=i*2;
> same as:
>   template exp(alias i){
>     alias exp=i*2;
>   }

Hmm, yeh not sure about that.  Have to get everyone to swallow the expression alias idea first, which will be tough because they've all been brainwashed into thinking that #define is the 8th deadly sin.  :-P

--bb