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.
Andrei says that it will (in a way) be both, so I'm happy with that.
I haven't seen that statement.
I can't find it, but he said that there will be two versions: a const
version and a non-const version. By default, the non-const version will
forward to the const version, so you only have to implement one.
