On 2/25/2019 8:22 AM, H. S. Teoh wrote:
> I disagree.  Logical const means the outside world can't tell that the
> object has changed, because only a constant value is ever seen from
> outside.  This is the basis of lazy initialization (which is part of the
> concept of lazy evaluation), an important feature of FP style code, and
> something that D does not support.

We've been through the logical const discussion before. The problem with it is it is not machine checkable. Therefore it's a documentation thing, not a language thing.

The not-machine-checkable attributes should be in the domain of user-defined attributes. It's what they're for.


> A derived problem with D's const is the inability to express a cached
> const object.  You can't cache the object because it's const, which
> greatly limits the scope of usability of const in large data structures.

I'd like to draw a distinction between where one can USE const as apposed to where const has VALUE. I propose that weakening const so it can be used on data that is mutated anyway means it can be put to USE much more often, at a heavy price of a severely diminished VALUE. It's why I pressed Manu about the VALUE of head const.


> The same limitation makes ref-counting such a huge challenge to
> implement in D.  There is simply no way to associate a refcount with a
> const object without jumping through hoops and/or treading into UB
> territory by casting away const. There is no way to express that the
> refcount is mutable but the rest of the object isn't. Well, you *can*
> express this if you use circumlocutions like:
> 
> 	struct RefCounted(T) {
> 		int refcount;
> 		const(T) payload;
> 	}
> 
> but that's worthless in generic code because const(RefCounted!T) !=
> RefCounted!(const T). So you have to special-case every generic function
> that needs to work with this type, and the special cases percolate
> through the entire codebase, uglifying the code and forcing generic
> functions that shouldn't need to know about RefCounted to have to know
> about it so that they can work with it.

We're well aware of that issue. The lack of copy-constructors was the first big barrier to getting ref counting working properly.


> Because of these limitations, const is really only useful in low-level
> modules of limited scope, in simple, self-contained data structures.
> Higher-level, larger data structures are basically unusable with D's
> const because lazy initialization and caching are not possible without
> treading into UB territory by casting.  I'm not going to argue that
> C++'s version of const is any better -- because non-enforceable const is
> worthless, like you said -- but let's not kid ourselves that D's const
> is that much better.  D's const is really only usable in very limited
> situations, and there are many things for which it's unusable even
> though logically it *could* have been applicable.

We'll see. I've been slowly getting better at refactoring code so I can use const, and as I've recounted before, the results are quite pleasing.

On 2/25/2019 7:45 AM, Atila Neves wrote:
> I have no idea what people are talking about when they mention on this forum that D's const is useless. Nearly every function parameter in my code is `in`. Nearly every variable declaration uses `const` instead of `auto`, the main exception being when a function is constructing a value to return. Most member functions I write are const or inout. I use const in D as I do in C++: pretty much everywhere. Nearly every single time a function parameter in my code isn't const is when it's an input range.

I'm going to make an educated guess that you're experienced at FP programming!

On 2/25/2019 10:44 AM, Andrei Alexandrescu wrote:
> On 2/25/19 1:39 PM, Jacob Carlborg wrote:
>> On 2019-02-25 17:31, Andrei Alexandrescu wrote:
>>
>>> The proposers (Razvan and myself) and Walter (the reviewer) do not know how to make DIP 1018 better.
>>
>> That shouldn't justify accepting a DIP that might contain problems.
> 
> Definitely.
> 
>> But of course, if you don't think there are any problems.
> 
> Not talking for Walter, but generally acceptance implies that.

I can't guarantee there aren't problems (bugs) in the DIP, but I didn't find any more (the ones I did find Razvan fixed). If you're familiar with the C++ copy ctor, it is very similar, lending credence to the notion that there isn't a big problem left.

Regardless, we need to move forward with this, not wring hands wondering what to do.

On 2/25/2019 6:55 PM, Andrei Alexandrescu wrote:
> If there's something else I can do to atone, please let me know.

Pistols at dawn?

Or better yet, why don't I buy both of you a beer at DConf?

On 2/25/2019 3:05 PM, Olivier FAURE wrote:
> On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote:
>> For the same reason C++'s std::shared_pointer uses a non-const copy constructor.
> 
> Wait, no, I just checked, std::shared_pointer's copy constructor is const, even though it changes shared data. Ugh, that's just wrong.
> 
> (I kind of agree with Walter's point; I totally assumed the constructor would be non-const, since it mutates data it receives)

There's also no requirement that any arguments to constructors should be const. Why should copy-constructors be different?

On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:
> ...

It's funny that you keep wasting time posting/replying instead of fixing your DIP.

By the way like the other guy, I found disrespectful (With RazvanN7) use this topic as argument for your rejected DIP, instead to debate about what this one has to offer.

Donald.

On Mon, Feb 25, 2019 at 8:10 PM Donald via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:
> > ...
>
> It's funny that you keep wasting time posting/replying instead of fixing your DIP.

An hour typing rubbish on the forum is nothing compared to rebooting hundreds of days waiting on the review pipeline!

> By the way like the other guy, I found disrespectful (With RazvanN7) use this topic as argument for your rejected DIP, instead to debate about what this one has to offer.

I didn't do that, I raised an issue about const fundamentally, and
used my DIP to contrast the weird decision relating to const.
My post is a post about const. I then started replying to other
peoples responses along the way.

On 2/25/2019 7:17 PM, Manu wrote:
> I'm literally astonished that it's been agreed it's fine that
> a copy constructor can mutate the source... and I can't help but draw
> contrast to the exact same sorts of arguments that people were using
> to break my DIP,

Mutating the lvalue ref was not the issue, as I recall. It was conversion of the value to a temporary of a different type, then modifying the temporary, not the original.

https://digitalmars.com/d/archives/digitalmars/D/announce/DIP_1016--ref_T_accepts_r-values--Formal_Assessment_54145.html#N54345

It is not analogous to the mutable cpctor argument case, because there is no hidden conversion to a temporary.

On 2/25/2019 7:17 PM, Manu wrote:
> break my DIP

The review process is not about "why not add this feature" , but "why should we have this feature".

Additionally, it is most assuredly about finding flaws in it. Isn't it best to find out the flaws before going further with it than finding them in the field?

As I mentioned before, it's supposed to be brutal. Any testing/certification/review process is about trying to break it.

It has (hopefully) nothing to do with how hard (or little) you worked on it, nor the cut of your jib, nor acceptance (or not) of mediocrity/merit in other DIPs.

On Mon, Feb 25, 2019 at 9:30 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 2/25/2019 7:17 PM, Manu wrote:
> > break my DIP
>
> The review process is not about "why not add this feature" , but "why should we have this feature".
>
> Additionally, it is most assuredly about finding flaws in it. Isn't it best to find out the flaws before going further with it than finding them in the field?
>
> As I mentioned before, it's supposed to be brutal. Any testing/certification/review process is about trying to break it.
>
> It has (hopefully) nothing to do with how hard (or little) you worked on it, nor
> the cut of your jib, nor acceptance (or not) of mediocrity/merit in other DIPs.

I'm talking about this DIP. Allowing a mutable copy argument feels super weird.
The reasons are clear, but that doesn't make it feel less weird.
I feel like the problem is with const, not with this DIP, but I'm not
about to convince anybody, so we're all good here.