On Wednesday, 1 September 2021 at 10:32:41 UTC, Per Nordlöw wrote:

I started looking into this after a short discussion with Andrei :)

On Wednesday, 1 September 2021 at 10:32:45 UTC, deadalnix wrote:

Ignore that. An editing mistake.

On Tuesday, 31 August 2021 at 17:21:02 UTC, deadalnix wrote:

Moreover, Rust collections provides makes rich of static members such as [1]

C.with_capacity(size_t)

instead of guessing what C(42) means which have introduced bugs in my code previously.

Might be worthwhile considering making use of these patterns.

My containers make use of such static members.

[1] https://doc.rust-lang.org/std/vec/struct.Vec.html#method.with_capacity.

On 8/31/21 8:26 PM, Paul Backus wrote:

It's possible to forward, i.e.:

template Vector(T) if (isConst!T) { alias Vector = tailconst(.Vector!(Unqual!T)); }

If you look at arrays, const(T)[] is the same as tailconst(T[]). This would be similar.

The problem I have with any other approach is that the compiler doesn't understand the relationships, and you will run into weird corner cases. It can't correctly add or strip the qualifier to the correct members when calling compatible functions.

-Steve

On 8/31/21 8:52 PM, deadalnix wrote:

Isn't the reason they prohibited COW is because of the problems with it?

Not saying COW is terrible in all cases, just that a generic container (non-specialized usage) should not be COW. If you need that feature, you should have to ask for it, not have it be an implementation detail.

-Steve

On Wednesday, 1 September 2021 at 10:44:46 UTC, Per Nordlöw wrote:

I have adopted that style a lot lately and this is indeed much better than C(42).

On Wednesday, 1 September 2021 at 11:13:27 UTC, Steven Schveighoffer wrote:

Well I never experienced any problem with them, so did many other C++ users. As far as i am concerned, this was a net step backward.

That being said, the reason were due to iterator invalidation. There are several function in the string API that do not invalidate iterators, as per the C++ standard, and these function might end up copying the content of the string in some specific situations, which would invalidate iterators.

In practice, I think the main problem here is related to exposing the innards of the datastructure. An iterator that contains a reference to the container + index, rather than some kind of raw pointer for instance, could avoid that problem.

On Wednesday, 1 September 2021 at 11:04:41 UTC, Steven Schveighoffer wrote:

template Vector(T) if (isConst!T) { alias Vector = tailconst(.Vector!(Unqual!T)); }

This runs directly into the issue 1807 problem. The compiler has to recognize this specific pattern as meaningful, and if the programmer writes something semantically equivalent using a different pattern, their code will mysteriously break; e.g.,

alias TailConstOf(T) = tailconst(T);
alias Vector(T : const(U)) = TailConstOf!(.Vector!U);

With the implicit opCast/constructor approach (or the opHeadMutable approach), the compiler doesn't have to understand the relationships. It just needs to know the original type and the desired type, and call the appropriate user-defined function to perform the conversion.

On 9/1/21 7:57 AM, Paul Backus wrote:

template Vector(T) if (isConst!T) { alias Vector = tailconst(.Vector!(Unqual!T)); }

alias TailConstOf(T) = tailconst(T);
alias Vector(T : const(U)) = TailConstOf!(.Vector!U);

Right, we have to fix that problem anyway.

To further explain for readers, the issue is:

void foo(T)(Vector!(const(T)) arg);

This should accept a Vector!(const int) which is aliased as tailconst(Vector!int), but the compiler can't see how to infer T as int from tailconst(Vector!int). I think the implicit cast solution suffers from similar problems. It works fine if you use const(T)[], which is the standard we should strive for.

This is one of those longstanding issues that needs addressing.

It just means you need to handle all the implicit conversions, which is not trivial. The compiler already has rules for implicit const conversions, some of which have subtle pitfalls if you get them wrong. I'd rather utilize those mechanisms rather than relying on each type author to get them all right.

-Steve