On 3/19/12, Steven Schveighoffer wrote:
> What if you don't have std.random's source, all you (the compiler) have is
> the function signature?
I know there are what ifs, but in this case it's a template.
On Sun, 18 Mar 2012 22:46:56 -0400, James Miller wrote:
Another thing I have noticed, is that that compared to a cast,
to! is incredibly slow. Most of the time it doesn't matter, but
I was doing some work with noise generation, and found that casting
the floats to integers was an order of magn
On Sun, 18 Mar 2012 15:53:56 -0400, Andrej Mitrovic
wrote:
On 3/18/12, Manu wrote:
I'm finding that in this code I'm writing, casts are taking up more
space
on many lines than the actual term being assigned.
Another classic which fails to compile is:
import std.random;
ubyte c = unifor
>> Another thing I have noticed, is that that compared to a cast,
>> to! is incredibly slow. Most of the time it doesn't matter, but
>> I was doing some work with noise generation, and found that casting
>> the floats to integers was an order of magnitude faster than using
>> to!int.
>
>
> There's
Andrej Mitrovic:
Another classic which fails to compile is:
import std.random;
ubyte c = uniform(0, 256);
It's legit to ask a compiler to help in this case. But currently
the D type system can't help you here.
The D syntax and type system tell apart sharply run-time values
from compile-ti
On 3/18/12 4:12 PM, James Miller wrote:
On 19 March 2012 08:53, Andrej Mitrovic wrote:
Another classic which fails to compile is:
import std.random;
ubyte c = uniform(0, 256);
In the call uniform returns a number anywhere from 0 to and including
255, which can fit perfectly in a ubyte. But I
On 19 March 2012 08:53, Andrej Mitrovic wrote:
> Another classic which fails to compile is:
>
> import std.random;
> ubyte c = uniform(0, 256);
>
> In the call uniform returns a number anywhere from 0 to and including
> 255, which can fit perfectly in a ubyte. But I have to use a cast
> (which is
On Sun, 18 Mar 2012 20:30:15 +0100, Manu wrote:
On 18 March 2012 21:15, Tove wrote:
On Sunday, 18 March 2012 at 19:08:54 UTC, Manu wrote:
So D is really finicky with integer casts. Basically everything that
might
produce a loss of data warning in C is an outright compile error.
This resu
On 3/18/12, Manu wrote:
> I'm finding that in this code I'm writing, casts are taking up more space
> on many lines than the actual term being assigned.
Another classic which fails to compile is:
import std.random;
ubyte c = uniform(0, 256);
In the call uniform returns a number anywhere from 0
On 18 March 2012 21:15, Tove wrote:
> On Sunday, 18 March 2012 at 19:08:54 UTC, Manu wrote:
>
>> So D is really finicky with integer casts. Basically everything that might
>> produce a loss of data warning in C is an outright compile error.
>> This results in a lot of explicit casting.
>>
>> Now
On Sunday, 18 March 2012 at 19:08:54 UTC, Manu wrote:
So D is really finicky with integer casts. Basically everything
that might
produce a loss of data warning in C is an outright compile
error.
This results in a lot of explicit casting.
Now I don't take issue with this, actually I think it's
On Mar 18, 2012 3:09 PM, "Manu" wrote
> int x = 123456;
> x &= 0xFF; // x is now in range 0..255; now fits in a ubyte
> ubyte y = x; // assign silently, cast can safely be implicit
This is related to Go's infinitely sized constants. If an expression
produces a value out of range then brings it b
So D is really finicky with integer casts. Basically everything that might
produce a loss of data warning in C is an outright compile error.
This results in a lot of explicit casting.
Now I don't take issue with this, actually I think it's awesome, but I
think there's one very important usability
13 matches
Mail list logo
