May 14, 2012
Le 14/05/2012 04:47, Jonathan M Davis a écrit :
> They can be in almost all cases. The problem is the folks who want to have
> caching and/or lazy initiailization in their classes/structs. You can't cache
> the result of any of those functions (toHash being the main target for it) if
> they're const and pure except in overloads which _aren't_ const, making those
> functions more expensive in comparison to what they could be if they weren't
> required to be const. And lazy initialization becomes almost impossible,
> because if the member variables needed in those functions haven't been
> initialized yet when they're called, then you _can't_ initialize them. If
> getting the value that it _would_ be without actually initializing the member
> variable works, then you can do that if it hasn't been initialized, but if you
> can't do that (e.g. the variable _must_ be set only once), then you're
> screwed. And regardless of whether you can make it work with const, it _will_
> be less efficient.
>

Lazy initialization is more a problem than a solution when it comes to multithreading. And I'm afraid it is the future.

BTW, nothing prevent to define toString an non const and another as const. The const one cannot cache the result, but certainly can read it. And every method that is aware of the non const version will use it.

This whole thing is overinflated. This isn't a problem. I'm pretty sure that most code that will broke was actually already a bad idea in the first place.
May 14, 2012
Le 14/05/2012 21:04, Mehrdad a écrit :
> On Monday, 14 May 2012 at 18:52:06 UTC, deadalnix wrote:
>> The only reason I'd see a toSting function as non pure or non const is
>> memoize. It can be tackled with lib support in phobos.
>> What are other uses cases ?
>
> Not necessarily 'memoization' -- you could be instead querying
> another object for this information, which may not be const.
> (Say, a network connection.)

I'd argue that hiding such an operation in toString or similar stuff is what you want to avoid.
May 14, 2012
On Mon, 14 May 2012 15:07:30 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/14/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> Really, printf is the *only* reason to have this backwards compatibility
>> "feature", and I strongly wish we could get rid of it.
>
> printf is also unique in that it works when called in class
> destructors, which is sometimes needed for debugging (unlike writef
> which wants to allocate memory and then throws).

That's an excellent point.  But what a really mean is, I wish we could get rid of the requirement for interoperability between printf and writef.

Of course, we couldn't get rid of printf, it's part of the C runtime!

-Steve
May 14, 2012
On Mon, 14 May 2012 13:08:06 -0400, Tove <tove@fransson.se> wrote:

> On Monday, 14 May 2012 at 16:53:24 UTC, Timon Gehr wrote:
>> On 05/14/2012 06:10 AM, Chris Cain wrote:
>>> On Monday, 14 May 2012 at 02:57:57 UTC, Mehrdad wrote:
>>>> The problem is that it's unavoidable.
>>>>
>>>> i.e. you can't say "don't mark it as const if it isn't const",
>>>> because, practically speaking, it's being forced onto the programmers
>>>> by the language.
>>>
>>> You're really against const in this language, huh?
>>>
>>
>> I guess this is not the most important point.
>> He has been trying to use const like in OO-ish C++.
>> This just does not work, because D const is detrimental to OO
>> principles when used that way.
>> The proposal is about _enforcing_ C++-like usage of const.
>
> but c++ has the 'mutable' keyword as an easy escape route... which saved me a bunch of times... guess one can emulate it with a library-solution using nested classes? But... what about structs?
>
> class Outer
> {
>    int i = 6; // mutable
>
>    class Inner {
>      int y=0;
>
>      int foo() const
>      {
>        // ++y; // fail
>        return ++i; // look ma, mutable const
>      }
>    }
>    Inner inner;
>    this()
>    {
>      inner = new Inner;
>    }
>    alias inner this;
> }

I have never seen this suggested before.  I would guess that it might be
considered a bug, since you are accessing the outer instance via a pointer
contained in the inner instance.

But I like the approach (even if it is a bug)!

-Steve
May 14, 2012
On Monday, 14 May 2012 at 19:13:30 UTC, deadalnix wrote:
> Le 14/05/2012 21:04, Mehrdad a écrit :
>> On Monday, 14 May 2012 at 18:52:06 UTC, deadalnix wrote:
>>> The only reason I'd see a toSting function as non pure or non const is
>>> memoize. It can be tackled with lib support in phobos.
>>> What are other uses cases ?
>>
>> Not necessarily 'memoization' -- you could be instead querying
>> another object for this information, which may not be const.
>> (Say, a network connection.)
>
> I'd argue that hiding such an operation in toString or similar stuff is what you want to avoid.

Uhm, I beg to differ...

What, exactly, is wrong with asking a non-const object for your toString() information?
May 14, 2012
On Mon, 14 May 2012 15:23:59 -0400, Steven Schveighoffer
<schveiguy@yahoo.com> wrote:

> On Mon, 14 May 2012 15:07:30 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> On 5/14/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>> Really, printf is the *only* reason to have this backwards compatibility
>>> "feature", and I strongly wish we could get rid of it.
>>
>> printf is also unique in that it works when called in class
>> destructors, which is sometimes needed for debugging (unlike writef
>> which wants to allocate memory and then throws).
>
> That's an excellent point.  But what a really mean is, I wish we could get rid of the requirement for interoperability between printf and writef.
>
> Of course, we couldn't get rid of printf, it's part of the C runtime!

Oh, and also, we should fix that problem (that writef allocates).
However, I think we need DIP9 in order to do that.
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

-Steve
May 14, 2012
On Mon, 14 May 2012 15:05:01 -0400, Alex Rønne Petersen
<xtzgzorex@gmail.com> wrote:

> On 14-05-2012 21:04, Mehrdad wrote:
>> On Monday, 14 May 2012 at 18:52:06 UTC, deadalnix wrote:
>>> The only reason I'd see a toSting function as non pure or non const is
>>> memoize. It can be tackled with lib support in phobos.
>>> What are other uses cases ?
>>
>> Not necessarily 'memoization' -- you could be instead querying
>> another object for this information, which may not be const.
>> (Say, a network connection.)
>
> That's actually a very, very good point.
>

Yes, the use case for logical const is when an object *doesn't own* a
reference.  I proposed a logical const solution a long time ago that
called it "nostate" instad of "mutable".

But there is a really big problem with logical const that makes it not
seem worth the trouble  of having it -- the syntax.  You would need a lot
of keywords and/or features to correctly describe relationships between
objects.  I just don't think people would tolerate it.

Hm... I just had a really good idea (I will divulge it in another post) on
how to implement logical const without altering the language and/or
compiler.

-Steve
May 14, 2012
Le 14/05/2012 21:24, Steven Schveighoffer a écrit :
> On Mon, 14 May 2012 13:08:06 -0400, Tove <tove@fransson.se> wrote:
>
>> On Monday, 14 May 2012 at 16:53:24 UTC, Timon Gehr wrote:
>>> On 05/14/2012 06:10 AM, Chris Cain wrote:
>>>> On Monday, 14 May 2012 at 02:57:57 UTC, Mehrdad wrote:
>>>>> The problem is that it's unavoidable.
>>>>>
>>>>> i.e. you can't say "don't mark it as const if it isn't const",
>>>>> because, practically speaking, it's being forced onto the programmers
>>>>> by the language.
>>>>
>>>> You're really against const in this language, huh?
>>>>
>>>
>>> I guess this is not the most important point.
>>> He has been trying to use const like in OO-ish C++.
>>> This just does not work, because D const is detrimental to OO
>>> principles when used that way.
>>> The proposal is about _enforcing_ C++-like usage of const.
>>
>> but c++ has the 'mutable' keyword as an easy escape route... which
>> saved me a bunch of times... guess one can emulate it with a
>> library-solution using nested classes? But... what about structs?
>>
>> class Outer
>> {
>> int i = 6; // mutable
>>
>> class Inner {
>> int y=0;
>>
>> int foo() const
>> {
>> // ++y; // fail
>> return ++i; // look ma, mutable const
>> }
>> }
>> Inner inner;
>> this()
>> {
>> inner = new Inner;
>> }
>> alias inner this;
>> }
>
> I have never seen this suggested before. I would guess that it might be
> considered a bug, since you are accessing the outer instance via a pointer
> contained in the inner instance.
>
> But I like the approach (even if it is a bug)!
>
> -Steve

Yes, you have similar bugs with delegates. This is a problem.
May 14, 2012
Le 14/05/2012 21:25, Mehrdad a écrit :
> On Monday, 14 May 2012 at 19:13:30 UTC, deadalnix wrote:
>> Le 14/05/2012 21:04, Mehrdad a écrit :
>>> On Monday, 14 May 2012 at 18:52:06 UTC, deadalnix wrote:
>>>> The only reason I'd see a toSting function as non pure or non const is
>>>> memoize. It can be tackled with lib support in phobos.
>>>> What are other uses cases ?
>>>
>>> Not necessarily 'memoization' -- you could be instead querying
>>> another object for this information, which may not be const.
>>> (Say, a network connection.)
>>
>> I'd argue that hiding such an operation in toString or similar stuff
>> is what you want to avoid.
>
> Uhm, I beg to differ...
>
> What, exactly, is wrong with asking a non-const object for your
> toString() information?

Nothing, expect it make it impossible to get that information on const/immutables objects.

Additionnaly, this operation isn't supposed to modify the object in any meaningfull way, or perform complex operation like connecting a remote database.
May 14, 2012
On 14.05.2012 23:26, Steven Schveighoffer wrote:
> On Mon, 14 May 2012 15:23:59 -0400, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>> On Mon, 14 May 2012 15:07:30 -0400, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com> wrote:
>>
>>> On 5/14/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>>> Really, printf is the *only* reason to have this backwards
>>>> compatibility
>>>> "feature", and I strongly wish we could get rid of it.
>>>
>>> printf is also unique in that it works when called in class
>>> destructors, which is sometimes needed for debugging (unlike writef
>>> which wants to allocate memory and then throws).
>>
>> That's an excellent point. But what a really mean is, I wish we could
>> get rid of the requirement for interoperability between printf and
>> writef.
>>
>> Of course, we couldn't get rid of printf, it's part of the C runtime!
>
> Oh, and also, we should fix that problem (that writef allocates).
> However, I think we need DIP9 in order to do that.
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
>

DIP9 for the win!
I tried to revive at least *some* interest in it for a long time.


-- 
Dmitry Olshansky