Hmm - about manifest/enum

[Walter Bright]

Derek Parnell wrote:
> Does the scheme allow a mutable pointer to immutable data? 
> 
> 	?? (const int)* p

Yes:
const(int)* p;


> Does the scheme allow an immutable pointer to mutable data? 
> 
> 	?? (int *) const p

No. If that's the omission you're referring to, I now understand your point.

> Does the scheme allow an immutable pointer to immutable data?
> 
> 	?? (const int)* const p

Yes:
const(int*) p;

> (and for completeness) Does the scheme allow a mutable pointer to mutable
> data?
> 
> 	?? int *p

Yes:
int* p;

> Can a mutable item become immutable at any time during the run time of an
> application?

Yes.

> Can you take a mutable copy of any immutable item?

Yes.

> And is the syntax to do
> this dependant on the data type of the original?

No, but if you want a deep copy, you'll have to implement .dup for your 
class/struct.

> Can you take a mutable copy of any immutable class object, struct or array?

Yes, but again you have to implement the dup if you want a deep copy.

> And is the syntax to do this dependant on the data type of the original?

No.

>>> you have decided are acceptable for
>>> us. Both of those, I foresee, will add to the cost of maintenance.
>> It's difficult to tell what is right without using it for a while.
> 
> That idea does not apply to everything in life. I have not used cigarettes
> but I know they are not right. 

I've never smoked because I know I'd like it, and I'd never get that 
monkey off my back. But there is plenty of experience on smoking - you 
know exactly what you're in for if you take it up.


> Also "goto" can be shown to increase the cost of program maintenance
> without having to actually use it to demostrate this effect.
> 
>>> The D programming language already has too many over-used keywords and
>>> poorly chosen keywords.
>> Some have also argued that it has too many keywords, period.
> 
> I have not heard that comment from anyone.

I have.


>>> The current decision to reuse 'enum' for manifest constants is yet another
>>> example of a designer believing that their intuition is better than their
>>> customers', regardless of any evidence to the contrary. Please reconsider
>>> that there might be a remote possibility that this decision is actually
>>> wrong in this case; 'enum' is not the best choice for developers when it
>>> comes to declaring manifest constants.
>> There are a number of people who strongly feel it is the correct 
>> decision who are not vocal about it.
> 
> If they are not vocal, how do you know about them?

They email me. There are many D users who do not participate here, but 
are still very much involved with D.

> Can you give numbers?

About as many as post here against it. There are also those who believe 
this is a tempest in a teapot, that we should be arguing about more 
important things :-)


>>> And yes, after using it for awhile we will get used to it, but that is not
>>> a reason for having it in the first place. We can get accustomed to the
>>> wart on our partners' nose but it will always be a wart.
>>>
>>> The arguments to date for 'enum' boil down to (1) its easier to implement
>>> given the current state of the D compiler,
>> Actually it's easier to invent another keyword.
> 
> That is good news then.
> 
>>> (2) C++ sort of, kind of, uses it sometimes like that, and
>> I brought up the C++ thing in the context of showing that enum is 
>> already routinely used for similar things.
> 
> And just like there are many of the bad things in C++ that have made it
> into D, right? Oh hang on, that's why you started D, to rid us of the
> misuse and insanity of some C++ idioms.

I guess one man's insanity is another man's sanity! Regardless of that, 
however, I think the C++ usage of it shows that people aren't so 
terribly confused about it, even if they don't like it.

>>> (3) you think its better than anything else.
>> That's not really an argument as to why I think it's the best option <g>.
> 
> I know that. But it has been used anyway.
>  
>>> Could it be that your point of view is not always the same as the
>>> developers' trying to use D?
>> All I can say is try using it for a while. Give it a chance, and then 
>> see what you think. I initially got criticized a lot for using !( ) for 
>> templates rather than < >, but I think that time has shown it was a good 
>> decision.
> 
> Actually I think that both < > and !() suck big time.

What would you have preferred?