On 29/09/11 6:50 PM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
<peter.alexander...@gmail.com> wrote:
On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
<peter.alexander...@gmail.com> wrote:
On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
<peter.alexander...@gmail.com> wrote:
I'm happy to not have logical const in D provided that the Object
interface (and other similar interfaces) don't require that opEquals
is const or any nonsense like that. const means physical const, and
opEquals should not require physical const.
IMO const/immutable should *only* be used when you need to pass
things
between threads i.e. when you *really do* need physical const. If
people start using const like you would in C++ then every interface
just becomes unnecessarily restrictive.
FYI, this is a bug, not a feature.
http://d.puremagic.com/issues/show_bug.cgi?id=1824
It *will* be fixed eventually. The fact that opEquals is not const
is a
huge problem.
-Steve
I was arguing that opEquals (and co.) should *not* be const. IMO it
would be a huge problem if they were.
why? For what purpose do you need to change an object during comparison?
The comparison may involve comparing a sub-object that is lazily
created. It could also involve computing a cached perfect hash for
faster comparison, requiring memoization.
Neither of these are required for opEquals to work. They are optimizations.
So what you're saying is that, in D, I'm not allowed to optimize my
opEquals and that I should be fine with that?
