On 12/07/2012 21:27, Jonathan M Davis wrote:
> On Thursday, July 12, 2012 20:42:49 David Piepgrass wrote:
>> - 'const' is not overly harsh if the user has machanisms to make
>> that mean 'logical const'.
>
> That will _never_ happen. That completely destroys a number of the benefits of
> const, and it adds quite a bit of cognitive load in dealing with const,
> because all of a sudden, you have to worry about whether _this_ const means
> actual const or logical const. It would also complicate the compiler's
> handling of const by quite a bit. Not to mention, Walter hates logical const
> in general, so he wouldn't support it. So, no, it's not going to happen.
>
> If we get any kind of logical const, it's going to be separate from const.
> const always has been and always will be physical const in D.
>
> - Jonathan M Davis

This has been discussed and isn't as dumb as you may think. What is important for us is that const provide the guarantee to never mutate immutable data.

Expressed that way, it can be loosened is some cases, in such a way that immutable data can never mutate throw const, but mutable one could.

I'm not for or against that, but it is certainly something to keep in mind when facing language evolution. We have that door ready to open.

On 7/12/12 4:50 PM, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 16:27:39 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 7/12/12 4:20 PM, Steven Schveighoffer wrote:
>>> I think this discussion is somewhat academic at this point, as Andrei
>>> seems not too keen on the idea of having dual base classes.
>>
>> Well I wasn't keen on eliminating the four methods and look what
>> happened!
>
> My personal opinion is we should simply eliminate the four methods (or
> at least the three required for AAs), fix AAs, and deal with the
> fallout. I can't really remember the last time I simply used
> obj1.opEquals(obj2) to do comparisons instead of obj1 == obj2 (which
> should do the right thing if obj1.opEquals(obj2) is valid). The code
> that relies on this is probably very rare. I certainly would *love* to
> rewrite all my opCmp and opEquals functions to accept the minimal base
> class instead of doing the dual dispatch dance with Object parameters.

I agree not a lot of people use obj1 == obj2 instead of obj1.opEquals(obj2), but I assume quite a few override opEquals and rely on it being called.

Andrei

On 7/12/12 6:38 PM, Andrei Alexandrescu wrote:
> I agree not a lot of people use obj1 == obj2 instead of
> obj1.opEquals(obj2)

Um, I got those swapped. Sorry.

Andrei

On Thursday, 12 July 2012 at 19:38:03 UTC, Jonathan M Davis wrote:
> On the other hand, if you're dealing with your own class hierarchy, you can choose what you're going to mark as const or not



Say person X who develops a class A with a const member similar to opEquals or whatever suits your fancy.

Say person Y is using person X's library (person X doesn't even _know_ person Y, let alone show him the source code), and finds that too restricting. It's being "forced onto them".



Could you tell me how this situation is different from the above?

How is person Y supposed to solve this problem? Modify the declarations? cast()?

On 07/13/2012 10:04 AM, Mehrdad wrote:
> On Thursday, 12 July 2012 at 19:38:03 UTC, Jonathan M Davis wrote:
>> On the other hand, if you're dealing with your own class hierarchy,
>> you can choose what you're going to mark as const or not
>
>
>
> Say person X who develops a class A with a const member similar to
> opEquals or whatever suits your fancy.
>
> Say person Y is using person X's library (person X doesn't even _know_
> person Y, let alone show him the source code), and finds that too
> restricting. It's being "forced onto them".
>
>
>
> Could you tell me how this situation is different from the above?
>
> How is person Y supposed to solve this problem? Modify the declarations?
> cast()?

Again, it's a matter of choice. You can always choose to use a particular library, alternative, or implement your own solution. How to you choose *not* to derive your classes from Object?

On Friday, 13 July 2012 at 01:10:16 UTC, Mike Parker wrote:
> Again, it's a matter of choice. You can always choose to use a particular library, alternative, or implement your own solution. How to you choose *not* to derive your classes from Object?


You mean, "how do you choose *not* to use opEquals()?"?

On Friday, 13 July 2012 at 01:10:16 UTC, Mike Parker wrote:
> Again, it's a matter of choice. You can always choose to use a particular library, alternative, or implement your own solution. How to you choose *not* to derive your classes from Object?


You mean, "how do you choose *not* to use opEquals()?"?

On Friday, July 13, 2012 10:10:14 Mike Parker wrote:
> On 07/13/2012 10:04 AM, Mehrdad wrote:
> > On Thursday, 12 July 2012 at 19:38:03 UTC, Jonathan M Davis wrote:
> >> On the other hand, if you're dealing with your own class hierarchy, you can choose what you're going to mark as const or not
> > 
> > Say person X who develops a class A with a const member similar to opEquals or whatever suits your fancy.
> > 
> > Say person Y is using person X's library (person X doesn't even _know_ person Y, let alone show him the source code), and finds that too restricting. It's being "forced onto them".
> > 
> > 
> > 
> > Could you tell me how this situation is different from the above?
> > 
> > How is person Y supposed to solve this problem? Modify the declarations?
> > cast()?
> 
> Again, it's a matter of choice. You can always choose to use a particular library, alternative, or implement your own solution. How to you choose *not* to derive your classes from Object?

Exactly.

const, @safe, pure, nothrow, etc. all provide benefits and guarantees, but they also place certain restrictions on your code. In most cases, those restrictions are just fine, so there's great benefit in using them. In rarer cases, those restrictions are too much (e.g. you must have lazy loading in your object or you need to be able to have equality based on database queries), in which case you just avoid the attributes that are incompatible with the idiom or approach that you're using.

If a 3rd party library works with what you're trying to do and fulfill your needs, then you may use it. If it doesn't work with what you're trying to do, then you don't. It can be annoying if you'd really like to use a particular library and can't because of its design decisions, but that can happen completely separately from const, pure, etc. But with a 3rd party library, you generally have options - there are always other libraries, whereas with the language itself, if it has a particular restriction disallows what you're trying to do, then you're going to have to not use that language. There's big difference between a library and a the language itself.

- Jonathan M Davis

On Friday, July 13, 2012 03:15:41 Mehrdad wrote:
> On Friday, 13 July 2012 at 01:10:16 UTC, Mike Parker wrote:
> > Again, it's a matter of choice. You can always choose to use a particular library, alternative, or implement your own solution. How to you choose *not* to derive your classes from Object?
> 
> You mean, "how do you choose *not* to use opEquals()?"?

Yes. Restrictions placed on Object affect _everyone_ using the language, whereas restrictions placed on a particular library only affect the users of that library. So, Object needs to be able to work without forcing const on anyone using it, whereas a 3rd library doesn't necessarily need to.

- Jonathan M Davis

On Friday, 13 July 2012 at 01:22:59 UTC, Jonathan M Davis wrote:
> There's big difference between a library and a the language itself.

Surely that's a non sequitur... Aren't we modifying druntime here?
What part of this has to do with the _language_? Isn't druntime a library?

Also, why can't you tell the user, "it's open-source! If it doesn't suit your needs, go modify it! Removing const is trivial!"
What makes it so easy to say that about every library /except/ druntime?



>> You mean, "how do you choose *not* to use opEquals()?"?

> Yes. Restrictions placed on Object affect _everyone_ using the language, whereas restrictions placed on a particular library only affect the users of that library. So, Object needs to be able to work without forcing const on anyone using it, whereas a 3rd library doesn't necessarily need to.


1. Again, see above -- Object is also in a library. Why doesn't the reasoning apply there? It's trivial to remove const from the library and recompile it -- _FAR_ easier than it is to modify any arbitrary library. (Speaking of which, thanks for making it so easy to modify & recompile druntime!)


2. Isn't it kinda /trivial/ to avoid opEquals? Just don't use it. Make up your own method. What's wrong with this?