Walter Bright Wrote:

> 'define' has been proposed before. I'd prefer to stay away from it because of the negative connotations of C's preprocessor.

How about 'let' then?
It works for FP..

Or just 'def': it is a good short version of 'definite' in the way that 'int' is short for 'integer' and 'const' is short for 'constant'.

However, surely anyone can see that without a '#' in front 'define' is very different to '#define'.

s

"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> What happens if you have this?
>> const(T)*[]
>
> Array of pointers to constant T.
>
>> If T is a struct, then it's fine, but if it's a class, then what?  To me the situation is just as bad.
>
> It is perfectly consistent. I don't see why it is bad.

const(T)*[] x;

x[0].member is a struct member if T is a struct, what is it if T is a class? I was under the (possibly wrong) impression that this is illegal?

>
>> This whole problem stems from the fact that a struct declaration is a value type and a class declaration is a reference type, but they look the same. You are never going to have a consistent syntax for generic const code because you don't have a consistent syntax for normal declarations.
>
> Having distinctly different value and reference aggregates is, in my opinion, a good thing.

I totally agree.  I don't think struct variables should become references. I was saying there should be a way to mean "reference to either struct or class" to make generic code with tail-constness easier to write

>> const (X)* m;
>>
>> Please tell me how you will replace m with a 'smart' pointer type that is mutable, but the pointer contents are not.
>
> That's the way it works now. You can modify m, but not X.

Sure, but your original point was to be "able to wrap any type with a
struct, and have it be possible for that
struct to behave as if it were that member type".  I believed you were
implying that this was a reason NOT to have a & operator.  My question to
you is, how does having a reference operator make this more difficult than
not having one?  A reference is a pointer.  We already have those, I have no
reason to believe that they are any less wrappable than a pointer?

>>> And finally, this suggests that & means "tail-const". Tail-const has that severe problem that there is no such thing as a tail-const member function (i.e. a member function that can modify the fields of the object, but not anything those fields refer to).
>>
>> Huh?  I thought tail-const was that you could change the reference but not the members?
>
> Yes, that's exactly what tail-const is.

OK, I am confused, isn't const(S)* tail const?  And if so, how does this new scheme rid us of tail const?  Couldn't I use this to call a const member function on a struct?

The way I am interpreting your new const is that I can have tail-const for struct references (pointers) but not tail-const for class references.  It seems to me it would be more important to have classes be const, why is your new way better?

In other words, I can create a tail-const struct array via:

const(S)*[] tailconst;
tailconst[0] = new S; // ok to assign to tailconst[0]
tailconst[0].nonconstfunc; // error, cannot call const function

How do I do the same for a class?  I don't want to have to use a * operator because I don't have to do that for structs.  I want to make generic code.

-Steve

sambeau Wrote:

> Walter Bright Wrote:
> 
> > I'd prefer to stay away from it because of the negative connotations of C's preprocessor.

On reflection, I don't think that's a good reason at all.
The principal of least surprise is, I feel, more important.
'enum' was, in my opinion, always a slightly dodgily named construct at the best of times.
Enumeration, to me, implies more than one thing.

I feel, with all due respect (and a lot of deference) :-), that you are being a language implementor, looking at the guts of your implementation and asking "what else is this like?" rather than asking yourself (as a language designer) and saying "how best can I express this concept using terms most people will understand".

Enum is just weird in this respect. It feels wrong.

sambeau wrote:
> sambeau Wrote:
> 
>> Walter Bright Wrote:
>>
>>> I'd prefer to stay away from it because of the negative connotations of C's preprocessor.
> 
> On reflection, I don't think that's a good reason at all.
> The principal of least surprise is, I feel, more important.
> 'enum' was, in my opinion, always a slightly dodgily named construct at the best of times.
> Enumeration, to me, implies more than one thing.
> 
> I feel, with all due respect (and a lot of deference) :-), that you are being a language implementor, looking at the guts of your implementation and asking "what else is this like?" rather than asking yourself (as a language designer) and saying "how best can I express this concept using terms most people will understand". 
> 
> Enum is just weird in this respect. It feels wrong.

Well, there are anonymous enums, right? /me hasn't used enums in quite some time.

So it's just letting you use all primitives with an enum, not just arithmetic types.

Walter Bright wrote:
> Ary Borenszweig wrote:
>> Why not
>>
>> macro x = 3;
>> ?
> 
> It's been suggested several times. It doesn't make much aesthetic sense to do things like:
> 
>     macro int x = 3;

Well, macros like that would almost always refer to primitive types: ints, bools, strings, etc. So the type will be ommited most of the time. I can't come up with an example for a constant (like #define) that needs to declare it's type (in fact, #define doesn't declare a type). If it's an enum, you would say

macro foo = SomeEnum.value;

If it's a constant field in a type, it's the same way. If you want to have some constant initialized in a "static this", than it can't be done with the macro syntax.

Christopher Wright wrote:
> Well, there are anonymous enums, right?

Right. We already have:

enum { x = 3 }

Christopher Wright wrote:
> Walter Bright wrote:
>> Christopher Wright wrote:
>>>> I've given up on tail const in any of its forms. The new regime has no tail const, no head const, it's just const, and fully transitive const at that.
>>>
>>> So if I have:
>>> const(Foo)* t;
>>> the pointer is const and points to a const Foo?
>>
>> No, it is a mutable pointer to a const Foo. A const pointer to a const Foo would be:
>>     const(Foo*) t;
>>
>>> Will that fail?
>>
>> Yes, because T[] will be the same thing as const(Foo)[]. Hiding it behind an alias and a template won't change that <g>.
> 
> So why do arrays take their const status from their elements when pointers don't?

??? I think there's a misunderstanding here on what arrays are. Arrays consist of a pointer/length pair. As far as const goes, they are just like pointers.

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> Steven Schveighoffer wrote:
>>> What happens if you have this?
>>> const(T)*[]
>> Array of pointers to constant T.
>>
>>> If T is a struct, then it's fine, but if it's a class, then what?  To me the situation is just as bad.
>> It is perfectly consistent. I don't see why it is bad.
> 
> const(T)*[] x;
> 
> x[0].member is a struct member if T is a struct, what is it if T is a class? I was under the (possibly wrong) impression that this is illegal?

I don't understand. Exactly what is illegal?


> Sure, but your original point was to be "able to wrap any type with a struct, and have it be possible for that
> struct to behave as if it were that member type".  I believed you were implying that this was a reason NOT to have a & operator.  My question to you is, how does having a reference operator make this more difficult than not having one?  A reference is a pointer.

There's the problem we're having. While a class reference is implemented as a pointer 'under the hood', to the type system, it is not a pointer.


> OK, I am confused, isn't const(S)* tail const?

No. For const(int*), tail const of that construct would mean that the pointer is mutable while what it points to is not.


> And if so, how does this new scheme rid us of tail const?

It would say that const(int*) would mean an immutable pointer to an immutable int.

> Couldn't I use this to call a const member function on a struct?

I'm very confused as to what you're referring to.


> The way I am interpreting your new const is that I can have tail-const for struct references (pointers) but not tail-const for class references.

No. The correct interpretation is that all parts of the type within the ( ) are immutable.


> In other words, I can create a tail-const struct array via:
> 
> const(S)*[] tailconst;
> tailconst[0] = new S; // ok to assign to tailconst[0]
> tailconst[0].nonconstfunc; // error, cannot call const function
> 
> How do I do the same for a class?

You cannot separate the class reference from the class fields.

Walter Bright wrote:
> Ary Borenszweig wrote:
>> Why not
>>
>> macro x = 3;
>> ?
> 
> It's been suggested several times. It doesn't make much aesthetic sense to do things like:
> 
>     macro int x = 3;

So are you saying that it would be fine without the type qualifier, or that you don't like the use of "macro" here at all?

Sean Kelly wrote:
> Walter Bright wrote:
>> Ary Borenszweig wrote:
>>> Why not
>>>
>>> macro x = 3;
>>> ?
>>
>> It's been suggested several times. It doesn't make much aesthetic sense to do things like:
>>
>>     macro int x = 3;
> 
> So are you saying that it would be fine without the type qualifier, or that you don't like the use of "macro" here at all?

Since the optional type qualifier should be supported, it doesn't make sense.