On 03/07/2017 03:49 PM, H. S. Teoh via Digitalmars-d wrote:
Unfortunately, because strings are arrays, deprecating array comparisons
*will* break a *lot* of code.
Misunderstanding, string comparisons are legit because character
comparisons are legit. This is about deprecating array
On Tue, Mar 07, 2017 at 07:53:37PM +, Stefan Koch via Digitalmars-d wrote:
> On Tuesday, 7 March 2017 at 19:40:53 UTC, Andrei Alexandrescu wrote:
> > On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:
> > > (1) I may be remembering wrong, but I thought structs had always
> > > been
On Tuesday, 7 March 2017 at 19:40:53 UTC, Andrei Alexandrescu
wrote:
On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:
(1) I may be remembering wrong, but I thought structs had
always been
intended to be compared field-wise? I remember when working
on AA's
that the compiler would
On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:
(1) I may be remembering wrong, but I thought structs had always been
intended to be compared field-wise? I remember when working on AA's
that the compiler would emit a default implementation of opEquals that
did member-wise
e yet "break the bad
> code". The most backward-compatible solution is to define opCmp
> automatically to do a field-by-field lexicographical comparison. The
> most radical solution is disable ordering comparisons unless
> explicitly implemented by the user.
[...]
I wouldn
On Tuesday, 7 March 2017 at 02:51:37 UTC, Jonathan M Davis wrote:
If we can, we should probably make structs that have opCmp use
opCmp like they should, and those that don't continue to use
memcmp for the moment but get a deprecation message. Then after
whatever amount of time we think is
On 03/06/2017 10:44 PM, Nick Sabalausky (Abscissa) wrote:
On 03/06/2017 08:27 PM, Andrei Alexandrescu wrote:
* A struct S { int x; } compares differently on little endian and big
endian system (!)
This one is very surprising. How is that so, if both structs being
compared are of the same
l solution is disable ordering
comparisons unless explicitly implemented by the user.
There should be no assumption that structs are comparable, so the
later.
On 2017-03-07 04:44, Nick Sabalausky (Abscissa) wrote:
This one is very surprising. How is that so, if both structs being
compared are of the same endian-ness?
The structs for a given run will be of the same endian-ness. But if you
run the same code on two different systems, one with little
Nick Sabalausky (Abscissa) wrote:
On 03/06/2017 08:27 PM, Andrei Alexandrescu wrote:
* A struct S { int x; } compares differently on little endian and big
endian system (!)
This one is very surprising. How is that so, if both structs being
compared are of the same endian-ness?
if we're
On 03/06/2017 08:27 PM, Andrei Alexandrescu wrote:
* A struct S { int x; } compares differently on little endian and big
endian system (!)
This one is very surprising. How is that so, if both structs being
compared are of the same endian-ness?
ution is to define opCmp
> automatically to do a field-by-field lexicographical comparison. The
> most radical solution is disable ordering comparisons unless explicitly
> implemented by the user.
If we can, we should probably make structs that have opCmp use opCmp like
they sh
issues
The question is what to do to minimize breakage yet "break the bad
code". The most backward-compatible solution is to define opCmp
automatically to do a field-by-field lexicographical comparison. The
most radical solution is disable ordering comparisons unless explicitly
i
13 matches
Mail list logo
