On Saturday, 25 January 2014 at 13:43:25 UTC, Timon Gehr wrote:
Why not?
struct S{
auto opCmp(S r){ return float.nan; }
}
void main(){
S s;
assert(s!=s);
}
Yes, but only for floatingpoint types - you cannot overload the
!= operator for integral types and it will be deprecated
On 01/27/2014 02:46 PM, Dominikus Dittes Scherkl wrote:
On Saturday, 25 January 2014 at 13:43:25 UTC, Timon Gehr wrote:
On 01/25/2014 01:57 PM, Dominikus Dittes Scherkl wrote:
And then comparison cannot be implemented fully correct with the current
operator overloding system of D.
Why not?
On 1/27/14 6:13 AM, Timon Gehr wrote:
float opCmp(sint r){
if(isNan()||r.isNan()) return float.nan;
return valuer.value?-1:valuer.value?1:0;
}
Quite a nice trick.
Andrei
On Monday, 27 January 2014 at 14:13:36 UTC, Timon Gehr wrote:
So? It was the most convenient way to illustrate that I have
defined a not fully ordered type using opCmp.
Was not my idea to deprecate them :-/
And you cannot opverload opCmp in a way that the new defined
integer NaN
will not
On Friday, 24 January 2014 at 23:26:04 UTC, Brad Roberts wrote:
On 1/24/14 6:08 AM, Dominikus Dittes Scherkl wrote:
I had something very simple in mind:
1) get rid of the asymmetric T.min value
that always causes problems with abs()
2) instead use this special value as NaN
3) let NaN be the
On 01/25/2014 01:57 PM, Dominikus Dittes Scherkl wrote:
...
Walter wrote:
There's no NaN for integrals.
At least the carry-bit is already available in hardware. So the save
type doesn't incure much performance loss in operations. On the other
hand comparison, assignment and casts become slower
On Friday, 24 January 2014 at 22:59:08 UTC, Andrei Alexandrescu
wrote:
integral expressions are handled. For example I found it
ridiculous that unary - for uint returns uint. Walter talked
Fortunately most CPUS have ones-complement so the result is
correct if you only use one unsigned type.
On Saturday, 25 January 2014 at 17:15:56 UTC, Ola Fosheim Grøstad
wrote:
Fortunately most CPUS have ones-complement so the result is
Err... Two's complement. Nngh! Anyway, the basic idea is to
think of minus for unsigned integers as ~x + 1, not as a
operation using negative integers. Then it
On 1/25/14 9:15 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 24 January 2014 at 22:59:08 UTC, Andrei Alexandrescu wrote:
integral expressions are handled. For example I found it ridiculous
that unary - for uint returns uint. Walter talked
Fortunately most CPUS
On 1/25/14 9:35 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Saturday, 25 January 2014 at 17:15:56 UTC, Ola Fosheim Grøstad wrote:
Fortunately most CPUS have ones-complement so the result is
Err... Two's complement. Nngh! Anyway, the basic idea is to think of
minus
On Saturday, 25 January 2014 at 18:53:29 UTC, Andrei Alexandrescu
wrote:
Of course it does. It was the point of my post. It's just that
the type is surprising from a basic arithmetic viewpoint.
Yes, I agree. I think it is messy to have implicit promotion of
unsigned values. For signed ints
Timon Gehr wrote:
On 01/24/2014 11:33 PM, Walter Bright wrote:
...
2. types do not depend on particular runtime values (the whole notion of
static typing would fall apart if it did)
http://en.wikipedia.org/wiki/Dependent_type
http://en.wikipedia.org/wiki/Refinement_type#Refinement_types
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei Alexandrescu
wrote:
byte a = -128;
auto b = -a;
What type should b get? (of course byte but the value
doesn't fit!)
The type will be int.
Ah, ok. Of course the small types always become int.
But the problem would be the same with
long a
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei
Alexandrescu wrote:
int a = 2_000_000_000;
int b = a + a;
should not generate weird stuff like -294_967_296 (which it
Long discussion about signed/unsigned
On Friday, 24 January 2014 at 11:43:08 UTC, eles wrote:
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei
Alexandrescu wrote:
int a = 2_000_000_000;
int b = a + a;
should not generate weird stuff like
On Friday, 24 January 2014 at 12:25:13 UTC, Dominikus Dittes
Scherkl wrote:
On Friday, 24 January 2014 at 11:43:08 UTC, eles wrote:
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei
Alexandrescu wrote:
int a =
On Friday, 24 January 2014 at 13:30:06 UTC, Meta wrote:
On the Rust mailing list, there's recently been discussion
about auto-promotion to BigInt in case of overflow. Maybe
that's a discussion we should be having as well?
Nice idea. But is any overflow known at compile-time?
Also really
On Friday, 24 January 2014 at 12:25:13 UTC, Dominikus Dittes
Scherkl wrote:
On Friday, 24 January 2014 at 11:43:08 UTC, eles wrote:
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei
Alexandrescu wrote:
But that is
On 1/24/2014 2:40 AM, Dominikus Dittes Scherkl wrote:
Ah, ok. Of course the small types always become int.
But the problem would be the same with
long a = long.min;
auto b = -a;
does this return ulong (which could hold the correct result) or long (and a
wrong result)?
The negation operator
On Friday, 24 January 2014 at 19:03:59 UTC, Walter Bright wrote:
On 1/24/2014 2:40 AM, Dominikus Dittes Scherkl wrote:
Ah, ok. Of course the small types always become int.
But the problem would be the same with
long a = long.min;
auto b = -a;
does this return ulong (which could hold the
On 1/24/2014 1:39 PM, Dominikus Dittes Scherkl wrote:
On Friday, 24 January 2014 at 19:03:59 UTC, Walter Bright wrote:
On 1/24/2014 2:40 AM, Dominikus Dittes Scherkl wrote:
Ah, ok. Of course the small types always become int.
But the problem would be the same with
long a = long.min;
auto b =
On 01/24/2014 11:33 PM, Walter Bright wrote:
...
2. types do not depend on particular runtime values (the whole notion of
static typing would fall apart if it did)
http://en.wikipedia.org/wiki/Dependent_type
On 1/24/14 2:40 AM, Dominikus Dittes Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei Alexandrescu wrote:
byte a = -128;
auto b = -a;
What type should b get? (of course byte but the value doesn't fit!)
The type will be int.
Ah, ok. Of course the small types always become
On 1/24/14 6:08 AM, Dominikus Dittes Scherkl wrote:
On Friday, 24 January 2014 at 13:30:06 UTC, Meta wrote:
On the Rust mailing list, there's recently been discussion about auto-promotion
to BigInt in case
of overflow. Maybe that's a discussion we should be having as well?
Nice idea. But is
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei Alexandrescu
wrote:
On 1/23/14 4:09 AM, Dominikus Dittes Scherkl wrote:
There is one mistake in C that D proliverates:
The T.min value of signed types.
e.g.
byte a = -128;
auto b = -a;
What type should b get? (of course byte but the value
On 1/24/2014 3:25 PM, Brad Roberts wrote:
None of this is new. It comes up periodically and ends up in the typical place
of many feature requests, unimplemented. Create the type, share it, see who
uses it and how much they gain from the benefits and if they're worth the
costs. Conjecture will
On 1/24/14 4:25 AM, Dominikus Dittes Scherkl wrote:
On Friday, 24 January 2014 at 11:43:08 UTC, eles wrote:
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes Scherkl
wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei Alexandrescu wrote:
int a = 2_000_000_000;
int b = a +
There is one mistake in C that D proliverates:
The T.min value of signed types.
e.g.
byte a = -128;
auto b = -a;
What type should b get? (of course byte but the value doesn't
fit!)
Also getting the absolute value of some signed variable
need to return a different type or doesn't work
Dominikus Dittes Scherkl:
E.g. ubyte abs(byte) - this functions which can't even use a
template, or has anybody a good idea ho to express
unsigned T abs(T)(T x)?
I think this is not hard to do in D.
by the way: why wasn't short instead called word?
On most modern CPUs a word is longer
mentioned error:
abs(-128) = -128 because it returns the same type as the input
has.
I hate standard functions that produce bogous results.
This is why I think we would be better off with symmetric signed
types.
Would also provide a perfect init value just like FP: NaN.
Ok, it costs some
On Thursday, 23 January 2014 at 12:09:24 UTC, Dominikus Dittes
Scherkl wrote:
Also getting the absolute value of some signed variable
need to return a different type or doesn't work correct for all
input.
E.g. ubyte abs(byte) - this functions which can't even use a
template,
or has anybody a
On Thursday, 23 January 2014 at 16:52:14 UTC, Stanislav Blinov
wrote:
On Thursday, 23 January 2014 at 12:09:24 UTC, Dominikus Dittes
Scherkl wrote:
Also getting the absolute value of some signed variable
need to return a different type or doesn't work correct for
all input.
E.g. ubyte
On Thursday, 23 January 2014 at 16:54:29 UTC, Dominikus Dittes
Scherkl wrote:
Cool. So why it that not used in std.math.abs?
http://d.puremagic.com/issues/show_bug.cgi?id=8666
Andrei's comment sums it up pretty much. AFAIK there may also be
some portability considertaions when performing
On 1/23/14 4:09 AM, Dominikus Dittes Scherkl wrote:
There is one mistake in C that D proliverates:
The T.min value of signed types.
e.g.
byte a = -128;
auto b = -a;
What type should b get? (of course byte but the value doesn't fit!)
The type will be int.
Also getting the absolute value
On 1/23/2014 12:35 PM, Andrei Alexandrescu wrote:
On 1/23/14 4:09 AM, Dominikus Dittes Scherkl wrote:
What type should b get? (of course byte but the value doesn't fit!)
The type will be int.
As an aside, the C integral arithmetic rules are often criticized. However,
nobody has found
Walter Bright:
The huge advantage of the C rules is they are very widely
known, used, and understood.
And following them allows me to translate intricate C code to D
with less headaches.
Still, Go has adopted a different strategy...
Bye,
bearophile
On 1/23/2014 4:50 PM, bearophile wrote:
Walter Bright:
The huge advantage of the C rules is they are very widely known, used, and
understood.
And following them allows me to translate intricate C code to D with less
headaches.
Still, Go has adopted a different strategy...
I know.
1. Go
Walter Bright:
1. Go determines the type of (e1 op e2) as the type of the
first operand.
http://golang.org/ref/spec#Arithmetic_operators
I consider this not only surprising (as we expect + to be
commutative) but can lead to unexpected truncation, as in (byte
= byte + int32).
I don't
On 1/23/2014 5:44 PM, bearophile wrote:
So despite what the docs say, it seems the two types need to be the same for the
sum to work?
I was going by what the spec said.
While this program compiles:
package main
import (fmt)
func main() {
var x byte = 10;
var y int = 1000;
39 matches
Mail list logo
