Walter Bright wrote:
> Don Clugston wrote:
>> "Template instantiations can now accept alias parameters for local variables and nested functions."
>>
>> which is of great interest to me, since now meta.prettynameof!() can work with local variables; this will be significant for DDL and probably things like PyD as well.
>> But, the name mangling is really weird. It's totally different to the name mangling for static variables, for example.
> 
> What happens is when one of the parameters is an alias to a local, the template becomes a *nested* class/function, and is mangled like one.

OK, that makes sense -- that should prevent the alias from 'leaking out' from the function. Might take me a while to get my head around all the consequences, though <g>. Opens up lots of possibilities.

Walter Bright wrote:
> Don Clugston wrote:
>> "Template instantiations can now accept alias parameters for local variables and nested functions."
>>
>> which is of great interest to me, since now meta.prettynameof!() can work with local variables; this will be significant for DDL and probably things like PyD as well.
>> But, the name mangling is really weird. It's totally different to the name mangling for static variables, for example.
> 
> What happens is when one of the parameters is an alias to a local, the template becomes a *nested* class/function, and is mangled like one.

I think I've found a bug in a corner case:

template t (alias A) {...}

void g() {
  void f() {
//    t!(f);   // CASE 1 --->  template t is nested in both g and f.
 }
   t!(f);    // CASE 2 ---> template t is nested in g but not f.
}

If case 1 appears anywhere (even in a pragma(msg)), it changes the name mangling of case 2.
I think case 1 is wrong: an inner function is not inside itself.

Walter Bright wrote:
> Major new stuff! But please, let's discuss that over in the digitalmars.D group.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.173.zip

The file phobos/std_outofmemory.html is still missing from the dmd package.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> Major new stuff!

Belated congrats!!

At this rate we're well past 2.0 at end of year! :-)

And for anybody contemplating a book on D, don't include the last chapter! Reason is, the back cover of the book runs away from you at precisely the speed you're writing the next-to-last chapter!  :-)

Ok, so this one is about a feature of some releases ago, but you're releasing new features faster than what we can keep up and look at :P

Regarding array literals, it concerns me that each new literal "evaluation" will create a new instance. For example a literal inside a function will allocate a new instance every time the function is called. Likewise a literal inside a loop will allocate a new instance for every cycle of the loop!
This strikes me as both inefficient (as there is no simple way to use the opposite behavior: static/global instances) and inconsistent: other kinds of literals, like string literals, are not instanced per "evaluation" but instead are single/global/static instances.
Is there any particular reason for this behavior? Because if not I'm inclined to think it would be better that array literals work as string literals (global/static instances). If the new'ed-instance behavior is needed it could be easily emulated with dup'ing:
  ar = [1, 4, 9].dup;

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Ok, so this one is about a feature of some releases ago, but you're releasing new features faster than what we can keep up and look at :P

Aint that the truth. :)

> 
> Regarding array literals, it concerns me that each new literal "evaluation" will create a new instance. For example a literal inside a function will allocate a new instance every time the function is called. Likewise a literal inside a loop will allocate a new instance for every cycle of the loop!
> This strikes me as both inefficient (as there is no simple way to use the opposite behavior: static/global instances) and inconsistent: other kinds of literals, like string literals, are not instanced per "evaluation" but instead are single/global/static instances.
> Is there any particular reason for this behavior? Because if not I'm inclined to think it would be better that array literals work as string literals (global/static instances). If the new'ed-instance behavior is needed it could be easily emulated with dup'ing:
>   ar = [1, 4, 9].dup;
> 

I'm afraid that things have to be that way. It would make sense for array literals to be allocated only once if they were made of only constant values, but in cases like:

for(int i=0; i<100; i++)
{
   f( [i, i*i] );
}

I would expect a new instance to be created at each step in the loop.

Bruno Medeiros wrote:
> Ok, so this one is about a feature of some releases ago, but you're releasing new features faster than what we can keep up and look at :P
> 
> Regarding array literals, it concerns me that each new literal "evaluation" will create a new instance. For example a literal inside a function will allocate a new instance every time the function is called. Likewise a literal inside a loop will allocate a new instance for every cycle of the loop!
> This strikes me as both inefficient (as there is no simple way to use the opposite behavior: static/global instances) and inconsistent: other kinds of literals, like string literals, are not instanced per "evaluation" but instead are single/global/static instances.
> Is there any particular reason for this behavior? Because if not I'm inclined to think it would be better that array literals work as string literals (global/static instances). If the new'ed-instance behavior is needed it could be easily emulated with dup'ing:
>   ar = [1, 4, 9].dup;
> 

Agreed.  It also makes life interesting in that things that depend of an array having compile-time constant value fail:

  const bool[3] a = [true,false,true];
  static if(a[0]) {}

(and fail with the misleading error message "expression (a)[0] does not evaluate to a boolean").

This is ok though:
  static if([true,false,true][0]) {}

Another thing that should work is:

   static const int[3] a = [4,5,6];
   static const int[a[0]] b = [1,2,3,4];

test.d(17): a is used as a type
test.d(17): can't have associative array key of void[0]

Ok, that's maybe a different issue... but I bet if it weren't trying to interpret the above as an associative array it would be complaining that the value a[0] isn't constant.  :-)

Ah, here's a better example:

  static const int[2] sizes = [2,4];
  static const int[2] use_sizes = [sizes[0], sizes[1]];

>> staticdata.d(19): non-constant expression (sizes)[0]
>> staticdata.d(19): non-constant expression (sizes)[1]

--bb

Ivan Senji wrote:
> Bruno Medeiros wrote:
> 
>> Ok, so this one is about a feature of some releases ago, but you're releasing new features faster than what we can keep up and look at :P
> 
> 
> Aint that the truth. :)
> 
>>
>> Regarding array literals, it concerns me that each new literal "evaluation" will create a new instance. For example a literal inside a function will allocate a new instance every time the function is called. Likewise a literal inside a loop will allocate a new instance for every cycle of the loop!
>> This strikes me as both inefficient (as there is no simple way to use the opposite behavior: static/global instances) and inconsistent: other kinds of literals, like string literals, are not instanced per "evaluation" but instead are single/global/static instances.
>> Is there any particular reason for this behavior? Because if not I'm inclined to think it would be better that array literals work as string literals (global/static instances). If the new'ed-instance behavior is needed it could be easily emulated with dup'ing:
>>   ar = [1, 4, 9].dup;
>>
> 
> I'm afraid that things have to be that way. It would make sense for array literals to be allocated only once if they were made of only constant values, but in cases like:
> 
> for(int i=0; i<100; i++)
> {
>    f( [i, i*i] );
> }
> 
> I would expect a new instance to be created at each step in the loop.
> 

It doesn't even need to be dynamic values.  Given

for(int i=0; i<100; i++)
{
   f( [1, 42] );
}

You might have f modifying the array since D doesn't have good support for const:

void f(int[2] v) {
      v[0]++;
}

And then f([1,42]) after the first call becomes equivalent to f([2,42]) which would be bad.

--bb

Walter Bright wrote:
> Major new stuff! But please, let's discuss that over in the digitalmars.D group.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.173.zip

The relaxed rules for template alias parameters aren't documented in the spec. The example under 'global names' compiles now <g>.

Bruno Medeiros wrote:
> The file phobos/std_outofmemory.html is still missing from the dmd package.

I'll fix.