On Fri, 28 Dec 2007 21:59:54 +0100, "Jérôme M. Berger" wrote:

> 	Right. Replace "const" by "invariant" in my comment and the main
> point still stands: couldn't the compiler determine automatically if
> we take the address of an invariant variable and allocate memory for
> it or not based on that? This would remove the need for a special
> keyword/syntax for manifest constants: just declare them as
> "invariant" and let the compiler do the work.

In order to do that, won't the compiler need to have access to all the source code for the application? If so, how can the compiler do it when given some source code and some object code to build the application?

- --
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright wrote:
> Jérôme M. Berger wrote:
>> Walter Bright wrote:
>>> Jérôme M. Berger wrote:
>>>>     :(
>>> Yeah, I figure I'll get fricasseed over that one. The most compelling argument is that we already have 3 ways to declare a constant, adding a fourth gets very difficult to justify. As opposed to a minor extension to enums.
>>
>>     This is an artificial distinction: you *are* adding a fourth way to
>> declare a constant,
> 
> Not really, just loosened up the restrictions on enum. The implementation code is actually simpler <g>.

Surely you don't want to make a language that's less clear and/or pleasant for its users, because it's slightly easier to implement!

>> the only question is what syntax to use: either
>> a counter-intuitive extension to enums or a new keyword (or a minor
>> extension to the alias keyword as was suggested by somebody).
> 
> I found the "use an alias when declaring one constant" and "use an enum when declaring more than one constant" to be difficult to justify. It's like saying arrays with only one element should not be allowed.

But I thought from discussion that enum wasn't allowed to be used when declaring multiple manifest constants -- a rule more akin to saying that in some contexts it's legal to define arrays so long as they have exactly one element.

-- James

Janice Caron Wrote:

> On 12/28/07, "Jérôme M. Berger" <jeberger@free.fr> wrote:
> > > I understand your point, but also consider that adding yet a fourth way to declare constants
> 
> Actually, I think that's a fifth way. You may have forgotten about
> 
>     real pi() { return 3.14159265359; }
> 
> Since we would hope that
> 
>     real x = pi;
> 
> will be inlined by the compiler, it would yield the effect of a manifest constant! :)
> 

Except you need a specific set of compiler and linker options for that effect.
(-inline, -L--gc-sections)
No way to tell the compiler that you want a specific function inlined and
omitted from output.

On 12/28/07, Derek Parnell <derek@psych.ward> wrote:
> In order to do that, won't the compiler need to have access to all the source code for the application?

No.

(So the rest of your question, "If so..." doesn't apply)

That said, Walter has already explained that this idea presents difficulties pertaining to tail-constness, and so can't be done. Just - not for the reason that you're implying.

On Fri, 28 Dec 2007 22:56:27 +0000, Janice Caron wrote:

> On 12/28/07, Derek Parnell <derek@psych.ward> wrote:
>> In order to do that, won't the compiler need to have access to all the source code for the application?
> 
> No.

Why not?

If what we are talking about is having the compiler detect if some code is taking the address of a constant value, doesn't the compiler need to see the code that does that? And if that code is in an object file and not a source file, then how will the compiler find out that the address is being taken?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

John Reimer wrote:

> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>> 
>>> Jérôme M. Berger wrote:
>>>> :(
>>> Yeah, I figure I'll get fricasseed over that one.
>> 
>> And rightfully so. This is one of the worse decisions among the bad ones in the D history.
>> 
>>> argument is that we already have 3 ways to declare a constant, adding a fourth gets very difficult to justify. As opposed to a minor extension to enums.
>> 
>> Not good enough.
>> 
> 
> It'll do.  I'd say it's bad, but not that bad (I think "manifest" looked better, personally -- almost pays to go back in time and start adopting the ideas that worked several decades ago... if they indeed did work).
> 
> Like everything in D, it's one of:
> 
> (1) we eventually get used to it
> (2) it eventually gets rejected and deprecated by the designer(s)
> (3) or d gets abandoned. :-P

Considering that none of the "established" bad decisions from 1.0 seems to be fixed (yet) in 2.0, we are currently gaining in the bad end? Even if there is a lot of nice stuff in there too.

FWIW, I think enum is on the same level as foreach_reverse, although that one exposed the problem with keywording such a special case. The usecase implemented with enum is at least valid enough.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter Bright wrote:
> Steven Schveighoffer wrote:
>> Consider this:
>>
>> enum Foo { x = 'a' }
>>
>> Now we remove Foo:
>>
>> enum { x = 'a' }
>>
>> Now x is a char, where Foo.x was an int?  That is very confusing.
> 
> C, C++, and D already work that way.

No, they don't.  In C, x has integral type, whether the enum is named or not.  In C++, x is *not* an int, but rather its type is an enum type (named or not).  Naming the enum type does not affect the type of x in C or C++.

(The fact that C says that 'a' is an int and C++ says that it is
a char is a separate issue.)

> Such are in common use, and I've
> not heard a complaint that it is very confusing.

It apparently confuses D's designer -- what chance do us mere mortals have?!

-- James

Derek Parnell, el 29 de diciembre a las 08:43 me escribiste:
> On Fri, 28 Dec 2007 10:35:38 -0800, Walter Bright wrote:
> 
> > Sean Kelly wrote:
> >> The weird thing for me is that this will allow individual enums of any type but grouped enums of only numeric types.
> > 
> > The following will work:
> > 
> > enum
> > {
> >      x = 3,   // x is int
> >      y = 4L,  // y is long
> > }
> > 
> > The idea is that for anonymous enums, there is no type for the enumeration as a whole. Therefore, each member of the enumeration can have a different type.
> 
> Will your syntax allow declarations of single values? e.g.
> 
>   enum x = 3;
>   enum y = 4L;
> 
> Or will we have to use the {} form?
> 
>    enum {x = 3}
>    enum {y = 4L}

With this example, I guess Walter will say:

enum {
	x = 3,
	y = 4L
}

=)

But the original question still remains, will be enum x = 3; supported?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
You can do better than me. You could throw a dart out the window and hit
someone better than me. I'm no good!
	-- George Constanza

Derek Parnell wrote:
> If what we are talking about is having the compiler detect if some code is
> taking the address of a constant value, doesn't the compiler need to see
> the code that does that? And if that code is in an object file and not a
> source file, then how will the compiler find out that the address is being
> taken?

What happens is the compiler emits data to the object file whenever the address of a constant is taken, regardless of what module defines the constant. Then, the linker removes the duplicates.

James Dennett wrote:
> Walter Bright wrote:
>> Not really, just loosened up the restrictions on enum. The
>> implementation code is actually simpler <g>.
> 
> Surely you don't want to make a language that's less clear
> and/or pleasant for its users, because it's slightly easier
> to implement!

No, but a simple, clean implementation can be an indication of a simple, clean design. If the implementation is larded up with special case code, that's a flag that perhaps the users also see that lard.


>>> the only question is what syntax to use: either
>>> a counter-intuitive extension to enums or a new keyword (or a minor
>>> extension to the alias keyword as was suggested by somebody).
>> I found the "use an alias when declaring one constant" and "use an enum
>> when declaring more than one constant" to be difficult to justify. It's
>> like saying arrays with only one element should not be allowed.
> 
> But I thought from discussion that enum wasn't allowed to be used
> when declaring multiple manifest constants -- a rule more akin to
> saying that in some contexts it's legal to define arrays so long
> as they have exactly one element.

enum { X = 3, Y = 3L }

defines two manifest constants.