Alias makes a lot more sense to me than enum.

alias x = 5;
alias float[] y = [1.0,2.0,3.0];

Conceptually, the variable becomes an alias for the literal.

Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.

--bb

Bill Baxter wrote:
> Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.

Because we already use enums to declare constant values.

enum { x = 3 }

Bill Baxter wrote:
> Alias makes a lot more sense to me than enum.
> 
> alias x = 5;
> alias float[] y = [1.0,2.0,3.0];
> 
> Conceptually, the variable becomes an alias for the literal.
> 
> Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
> 
> --bb

FWIW, alias makes the most sense to me out of the current crop of suggestions.  To me it says that wherever I see the alias, it will be replaced with whatever value the alias is for.  That seems to describe manifest constants exactly.

Walter Bright wrote:
> Bill Baxter wrote:
>> Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
> 
> Because we already use enums to declare constant values.
> 
> enum { x = 3 }

Will enum be able to work as a modifier as in:

enum
{
    int x = 3;
    auto y = "hello";
}

...?

Also, unrelated, will there be a way to declare a class variable that is constant after construction (it is assigned once in the constructor, then doesn't change)?

David Gileadi Wrote:

> Bill Baxter wrote:
> > Alias makes a lot more sense to me than enum.
> > 
> > alias x = 5;
> > alias float[] y = [1.0,2.0,3.0];
> > 
> > Conceptually, the variable becomes an alias for the literal.
> > 
> > Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
> > 
> > --bb
> 
> FWIW, alias makes the most sense to me out of the current crop of suggestions.  To me it says that wherever I see the alias, it will be replaced with whatever value the alias is for.  That seems to describe manifest constants exactly.

This all makes sense as an implementation, but not as a language design.
You need to step back and look at the word 'enum' and ask yourself does it make sense?

Surely, if you are proposing to change the use of 'enum' in this significant way you should change it's name. Otherwise everyone will be confused.

Def, let, constants, defines,  ... , etc

They all have two advantages
1) they sound like what they do
2) they aren't a reuse of something that already does something

I know that many people always go on about how many reserved words a language has and treats it like a badge of honor. But we can't all be Lisp. I would rather use keywords that make sense than reuse the same keyword for more than one distinct use.. static, extrern, const, ..., blah! :-)

Walter Bright wrote:
> Bill Baxter wrote:
>> Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
> 
> Because we already use enums to declare constant values.
> 
> enum { x = 3 }

That is a trick to declare a constant. You can also do this:

class Constants {

	static int x = 3;

}

And then you refer it as

Constants.x

So a possible syntax for defining constants could be

class static int x = 3;

Robert Fraser wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
>>
>> Because we already use enums to declare constant values.
>>
>> enum { x = 3 }
> 
> Will enum be able to work as a modifier as in:
> 
> enum
> {
>     int x = 3;
>     auto y = "hello";
> }
> 
> ...?

I seriously doubt it <g>.


> Also, unrelated, will there be a way to declare a class variable that is constant after construction (it is assigned once in the constructor, then doesn't change)?

Yes, just don't supply an initializer for it:

class C
{
	const int x;
	this()
	{
		x = 3; // ok
	}
	void foo()
	{
		x = 3; // error, x is const
	}
}

David Gileadi wrote:
> FWIW, alias makes the most sense to me out of the current crop of suggestions.  To me it says that wherever I see the alias, it will be replaced with whatever value the alias is for.  That seems to describe manifest constants exactly.

Since there's already:

	alias X Y;

it would seem confusing to add:

	alias Y = X;

On Thu, 06 Dec 2007 21:07:18 -0800, Walter Bright wrote:

> David Gileadi wrote:
>> FWIW, alias makes the most sense to me out of the current crop of suggestions.  To me it says that wherever I see the alias, it will be replaced with whatever value the alias is for.  That seems to describe manifest constants exactly.
> 
> Since there's already:
> 
> 	alias X Y;
> 
> it would seem confusing to add:
> 
> 	alias Y = X;

I know it was asked before for sure,
but could someone point out why not just use:

alias Y 42;
alias Z "abc";
alias X [1,2,3];

- it points out that it doesn't have a memory address (no '=' assigment) - it will be filled in for X, Y, Z

btw.: enum for compile time constants doesn't fit it's
main meaning (enumeration), but it's secondary
meaning as compile time constants.
It's also limited (regarding to strings etc.).
I would call it a hack. :P

mandel wrote:
> On Thu, 06 Dec 2007 21:07:18 -0800, Walter Bright wrote:
> 
>> David Gileadi wrote:
>>> FWIW, alias makes the most sense to me out of the current crop of
>>> suggestions.  To me it says that wherever I see the alias, it will be
>>> replaced with whatever value the alias is for.  That seems to describe
>>> manifest constants exactly.
>> Since there's already:
>>
>> 	alias X Y;
>>
>> it would seem confusing to add:
>>
>> 	alias Y = X;
> 
> I know it was asked before for sure,
> but could someone point out why not just use:
> 
> alias Y 42;
> alias Z "abc";
> alias X [1,2,3];

No type safety.