On 21/03/2013 07:51, Jonathan M Davis wrote:
On Thursday, March 21, 2013 08:29:28 deadalnix wrote:
Wouldn't that trigger bunch of false warning on legitimate
overloaded opSomething ?
I'm not sure that overriding a deprecated function triggers a deprecation
warning, but regardless, for opEquals
On Thursday, March 21, 2013 08:29:28 deadalnix wrote:
> Wouldn't that trigger bunch of false warning on legitimate
> overloaded opSomething ?
I'm not sure that overriding a deprecated function triggers a deprecation
warning, but regardless, for opEquals and opCmp, that wouldn't be a problem,
bec
On Wednesday, 20 March 2013 at 04:39:14 UTC, Jonathan M Davis
wrote:
On Tuesday, March 19, 2013 20:51:28 Stewart Gordon wrote:
But the question still remains: How do we implement this
change without
causing mass disruption? It might be the case that
programmers just
need to remove opEquals(Obj
On Monday, March 18, 2013 00:19:03 Peter Williams wrote:
> So my question is "Why are the arguments to opEquals and opCmp
> (for Objects) not declared in or const?".
By the way, this is post where it was officially decided that we'd be working
on
removing opCmp, opEquals, toHash, and toString fr
On Tuesday, March 19, 2013 20:51:28 Stewart Gordon wrote:
> But the question still remains: How do we implement this change without
> causing mass disruption? It might be the case that programmers just
> need to remove opEquals(Object) and opCmp(Object) from their classes,
> and remove the overrid
On 19/03/2013 05:38, Jonathan M Davis wrote:
Well, IIRC, if when you override a function, and you give it a
different parameter type, it's a new overload rather than actually
overriding anything (even if the type of the parameter in the derived
type's function is a derived type of the type of th
On 19/03/13 15:38, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 02:17:28 Peter Williams wrote:
Am I right in thinking that removal of these methods from Object
will mean that it will no longer be necessary for the the
argument to be of type Object and that the need for casting in
the imple
On Tuesday, March 19, 2013 02:17:28 Peter Williams wrote:
> Am I right in thinking that removal of these methods from Object
> will mean that it will no longer be necessary for the the
> argument to be of type Object and that the need for casting in
> the implementation will go away?
Well, IIRC, i
On 19/03/2013 01:17, Peter Williams wrote:
Am I right in thinking that removal of these methods from Object will
mean that it will no longer be necessary for the the argument to be of
type Object
Yes, and that's indeed a potentially good reason to remove opCmp and
opEquals from Object, and on
On Tuesday, March 19, 2013 01:31:23 Stewart Gordon wrote:
> What I'm suggesting may be inefficient in complicated cases, but that's
> different from being impossible, which is what you're basically saying.
It _is_ impossible if it's in the type, because you can't modify const. Sure,
in same cases
On 19/03/2013 00:46, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 00:26:40 Stewart Gordon wrote:
Why can't it be used as a means of lazy initialization?
Because if one of the member variables hasn't been initialized yet, then it
can't be compared.
You miss the whole point of what I'm
On Monday, 18 March 2013 at 01:05:25 UTC, Jonathan M Davis wrote:
On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
Why would some class want to implement these methods in a way
that alters
the object?
Because const in D is physical const, not logical const. So,
for instance,
const pr
On Tuesday, March 19, 2013 00:26:40 Stewart Gordon wrote:
> On 18/03/2013 23:06, Jonathan M Davis wrote:
> > On Monday, March 18, 2013 22:11:49 Stewart Gordon wrote:
>
>
> >> Look up std.functional.memoize.
> >
> > It doesn't work with pure as it forces you to put state outside of the
> > object
On 19/03/2013 00:19, Jakob Ovrum wrote:
It's worth noting that including a standard interface (as in the
interface keyword) for stuff like Comparable, Hashable etc. is a
possibility that can be explored to enable runtime polymorphism akin to
the current Object for programs that need it. Either w
On 18/03/2013 23:06, Jonathan M Davis wrote:
On Monday, March 18, 2013 22:11:49 Stewart Gordon wrote:
Look up std.functional.memoize.
It doesn't work with pure as it forces you to put state outside of the object,
and it's only applicable to caching, not lazy initialization.
Why can't it be
On Monday, 18 March 2013 at 01:05:25 UTC, Jonathan M Davis wrote:
So, once all of those functions are removed from Object,
derived types can
then define them with whatever attributes they want. The only
thing you lose is
the ability to compare Objects directly, which is not necessary
in D and i
On Monday, March 18, 2013 22:11:49 Stewart Gordon wrote:
> On 18/03/2013 01:05, Jonathan M Davis wrote:
> > On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
> >> Why would some class want to implement these methods in a way that alters
> >> the object?
> >
> > Because const in D is physica
On Monday, March 18, 2013 23:53:05 Timon Gehr wrote:
> On 03/18/2013 11:11 PM, Stewart Gordon wrote:
> > ...
> >
> > But the drawback of this approach (compared with making Object
> > const-correct) is that some library programmers will (continue to)
> > neglect const-correctness
>
> That's a C++
On 03/18/2013 11:11 PM, Stewart Gordon wrote:
...
But the drawback of this approach (compared with making Object
const-correct) is that some library programmers will (continue to)
neglect const-correctness
That's a C++ term and it is not applicable to D.
On 18/03/2013 01:05, Jonathan M Davis wrote:
On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
Why would some class want to implement these methods in a way that alters
the object?
Because const in D is physical const, not logical const. So, for instance,
const prevents caching. And it'
On Monday, 18 March 2013 at 01:05:25 UTC, Jonathan M Davis wrote:
On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
Why would some class want to implement these methods in a way
that alters
the object?
Because const in D is physical const, not logical const. So,
for instance,
const pr
On Monday, March 18, 2013 02:00:37 Peter Williams wrote:
> Can't those (rare) implementations just do a non constant cast
> when they cast Object to their desired class?
No. In D, casting away const on an object and mutating it is undefined
behavior.
- Jonathan M Davis
On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
> Why would some class want to implement these methods in a way that alters
> the object?
Because const in D is physical const, not logical const. So, for instance,
const prevents caching. And it's quite possible that a type which really ca
On Monday, 18 March 2013 at 00:16:17 UTC, Timon Gehr wrote:
On 03/18/2013 12:19 AM, Peter Williams wrote:
The current signatures for opCmp/opEqual mean that code like:
bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
On 18/03/2013 00:34, Jonathan M Davis wrote:
On Monday, March 18, 2013 01:20:40 Timon Gehr wrote:
So my question is "Why are the arguments to opEquals and opCmp (for
Objects) not declared in or const?".
Because not all valid implementations can be. They shouldn't be in
Object anyway.
Yeah. I
On Monday, 18 March 2013 at 00:46:46 UTC, Stewart Gordon wrote:
On 17/03/2013 23:19, Peter Williams wrote:
So my question is "Why are the arguments to opEquals and opCmp
(for Objects) not declared
in or const?".
Known bug.
http://d.puremagic.com/issues/show_bug.cgi?id=1824
I did look in
On 17/03/2013 23:19, Peter Williams wrote:
So my question is "Why are the arguments to opEquals and opCmp (for Objects)
not declared
in or const?".
Known bug.
http://d.puremagic.com/issues/show_bug.cgi?id=1824
This was reported 5 years ago, and it's a serious issue, so I don't know why it's
On Monday, March 18, 2013 01:20:40 Timon Gehr wrote:
> >> So my question is "Why are the arguments to opEquals and opCmp (for
> >> Objects) not declared in or const?".
> >
> > Because not all valid implementations can be. They shouldn't be in
> > Object anyway.
Yeah. It was agreed that opCmp, opE
On 03/18/2013 01:16 AM, Timon Gehr wrote:
On 03/18/2013 12:19 AM, Peter Williams wrote:
The current signatures for opCmp/opEqual mean that code like:
bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
return f
On 03/18/2013 12:19 AM, Peter Williams wrote:
The current signatures for opCmp/opEqual mean that code like:
bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
return false;
}
return true;
}
will fail
The current signatures for opCmp/opEqual mean that code like:
bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
return false;
}
return true;
}
will fail to compile if T is a class because opCmp cannot be
31 matches
Mail list logo
