On 2/13/12 7:46 AM, David Nadlinger wrote:
> On 2/13/12 2:43 PM, Andrej Mitrovic wrote:
>> auto u = (a, b) => cast(ubyte)uniform(a, b);
>>
>> Which would make 'u' a template. I'm not sure what the exact syntax
>> was that was requested though.
>
> This could never work without major changes to the language, because 'u'
> cannot be assigned a type.
>
> David

alias (a, b) => cast(ubyte)uniform(a, b) u;

should work. This makes is a case where the discussed syntax "alias defined = definee;" would be helpful.

Andrei

"David Nadlinger" <see@klickverbot.at> wrote in message news:jhbdnb$21sb$1@digitalmars.com...
>>
>> auto u = function (int a, int b) =>  cast(ubyte)uniform(a, b);
>>
>> Should do it.
>
> I know it currently isn't, but shouldn't this be inferred as per TDPL anyway?
>
> David

Yes, it's just a way to force it.

On 2/13/12 11:21 AM, bearophile wrote:
> Zach the Mystic:
> Regarding pure random generators, I have asked it too:
> http://d.puremagic.com/issues/show_bug.cgi?id=5249

Aren't "pure" and "random" diametrically opposed in a fundamental way?

On 02/13/2012 06:01 PM, Zach the Mystic wrote:
> On 2/13/12 11:21 AM, bearophile wrote:
>> Zach the Mystic:
>> Regarding pure random generators, I have asked it too:
>> http://d.puremagic.com/issues/show_bug.cgi?id=5249
>
> Aren't "pure" and "random" diametrically opposed in a fundamental way?

They are. It is "pure" and "pseudo-random" that are not.

On 13 February 2012 17:01, Zach the Mystic <reachzachatgooglesmailservice@dot.com> wrote:
> On 2/13/12 11:21 AM, bearophile wrote:
>>
>> Zach the Mystic:
>>
>> Regarding pure random generators, I have asked it too: http://d.puremagic.com/issues/show_bug.cgi?id=5249
>
>
> Aren't "pure" and "random" diametrically opposed in a fundamental way?

I'd say it was an oxymoron.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 13-2-2012 15:14, bearophile wrote:
> Zach the Mystic:
>
>> void setRandomColorPair( ref ColorPair cp )
>> {
>>      import std.random;
>>      ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }
>
> Where possible it's good to add "static" to nested functions:


Why?

On 03/09/2012 02:29 PM, Jos van Uden wrote:
> On 13-2-2012 15:14, bearophile wrote:
>> Zach the Mystic:
>>
>>> void setRandomColorPair( ref ColorPair cp )
>>> {
>>> import std.random;
>>> ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }
>>
>> Where possible it's good to add "static" to nested functions:
>
>
> Why?

Because then you don't have to rely on the compiler to optimize away the unneeded context pointer parameter. It should be able to do that though. I don't know if DMD is.

Jos van Uden:

> On 13-2-2012 15:14, bearophile wrote:
>> Where possible it's good to add "static" to nested functions:
>
> Why?

For optimization, to be sure there's no closure allocation or a second pointer. But also for code correctness, because static functions can't use automatic variables defined in the enclosing function. This makes the code simpler to understand (the pure attribute has a similar purpose, you are sure your global function is not using global mutable variables).

Bye,
bearophile

On Monday, 13 February 2012 at 14:14:38 UTC, bearophile wrote:
> Zach the Mystic:
>
>> void setRandomColorPair( ref ColorPair cp )
>> {
>>     import std.random;
>>     ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }
>
> Where possible it's good to add "static" to nested functions:
>
> static ubyte u(in int a, in int b) pure nothrow { return cast(ubyte) uniform(a,b); }

I sorta figured D would implicitly attribute "static" to nested functions if the function didn't use any variables outside it's scope. Is that not so? Why are you saying it's a good idea to use "static" exactly?

F i L:

> I sorta figured D would implicitly attribute "static" to nested functions if the function didn't use any variables outside it's scope. Is that not so?

I don't think DMD does that. Before assuming DMD performs one optimization, go to read some of the asm it produces.


> Why are you saying it's a good idea to use "static" exactly?

Some answers here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=160469

Bye,
bearophile