Firstly, let me preface this... if you use templates to get
around the const system's imperfections, you are admitting that
the const system is broken. Now, on with the program.
My unique experience in using D2 without Phobos lead me to
encounter two cases that show how the D2 const system is just a
pain in the behind for some really reasonable tasks.
First case:
You want to sort an array of strings using a function. Strings
can be all of these types: char[], const(char)[] and
immutable(char)[]. What would be the signature of such a function?
It can't be sort(const(char)[][]) because it's unsafe to case
char[][] and immutable(char)[][] to that argument type (see
http://d.puremagic.com/issues/show_bug.cgi?id=4251 ).
It can't be sort(const(char[])[]) because you can't actually sort
that!
The only good way I found is to use a cast inside the function
with the second signature. Obviously I'm glad there's a
workabout, but surely a cast isn't a good thing.
Second case:
inout was meant to solve issues with functions that return slices
of inputs. What about a class that is dedicated to the same
functionality?
E.g. this works fine:
inout(char)[] half(inout(char)[]);
But what about this:
struct Slicer
{
char[] a;
char[] half();
}
Note that the type of the input (the member 'a') must be the same
as the output of the half method. I don't know how to accomplish
this without templates. But as I said in the preface, you
shouldn't need templates for such a simple task. Note that doing
this isn't satisfactory:
struct Slicer
{
char[] a;
inout(char)[] half() inout;
}
because there may be other members inside that struct that may
need to remain mutable.
This is very relevant, incidentally, for the planned library
implementation of associative arrays. How would this be
implemented when an associative array is a struct?
inout(char)[] test(inout(char)[])
{
inout(char)[][int] a;
}
It doesn't even compile now (in dmd 2.058).
I don't have any solutions to these problems, incidentally... I
think they are complex, but definitely worthy of having a
reasonable solution that doesn't involve needless (in this case)
templates.
-SiegeLord

Firstly, let me preface this... if you use templates to get around the
const system's imperfections, you are admitting that the const system is
broken. Now, on with the program.
My unique experience in using D2 without Phobos lead me to encounter two
cases that show how the D2 const system is just a pain in the behind for
some really reasonable tasks.
First case:
You want to sort an array of strings using a function. Strings can be
all of these types: char[], const(char)[] and immutable(char)[]. What
would be the signature of such a function?
It can't be sort(const(char)[][]) because it's unsafe to case char[][]
and immutable(char)[][] to that argument type (see
http://d.puremagic.com/issues/show_bug.cgi?id=4251 ).
It can't be sort(const(char[])[]) because you can't actually sort that!

The only good way I found is to use a cast inside the function with the
second signature. Obviously I'm glad there's a workabout, but surely a
cast isn't a good thing.

A type-safe workaround is to use the signature
inout(void) sort(inout(char)[][]);

Second case:
inout was meant to solve issues with functions that return slices of
inputs. What about a class that is dedicated to the same functionality?
E.g. this works fine:
inout(char)[] half(inout(char)[]);
But what about this:
struct Slicer
{
char[] a;
char[] half();
}
Note that the type of the input (the member 'a') must be the same as the
output of the half method. I don't know how to accomplish this without
templates. But as I said in the preface, you shouldn't need templates
for such a simple task. Note that doing this isn't satisfactory:
struct Slicer
{
char[] a;
inout(char)[] half() inout;
}
because there may be other members inside that struct that may need to
remain mutable.

This is very relevant, incidentally, for the planned library
implementation of associative arrays. How would this be implemented when
an associative array is a struct?
inout(char)[] test(inout(char)[])
{
inout(char)[][int] a;
}
It doesn't even compile now (in dmd 2.058).

It does. The problem is that your function is missing a return
statement. Anyway, when an associative array is a template struct then
there is basically no non-magical way to implement what you want.
However, if we introduce generics, the solution would look similar to
this sketch:
struct AssocArray(S, T)[K <: const(S), V <: const(T)]{
V lookup(K);
...
}
'test' would be rewritten by the compiler as:
inout(char)[] test(inout(char)[]) {
AssocArray!(int,char[])![int,inout(char)[]] a;
// ...
}

I don't have any solutions to these problems, incidentally... I think
they are complex, but definitely worthy of having a reasonable solution
that doesn't involve needless (in this case) templates.
-SiegeLord

The first problem is trivial, solving the second one in a type safe way
would require adding parametric polymorphism to D. (Which I'd love to have!)

Firstly, let me preface this... if you use templates to get around the
const system's imperfections, you are admitting that the const system is
broken. Now, on with the program.

Hold them horses. I disagree. You're just saying it, but what's your basis?

My unique experience in using D2 without Phobos lead me to encounter two
cases that show how the D2 const system is just a pain in the behind for
some really reasonable tasks.
First case:
You want to sort an array of strings using a function. Strings can be
all of these types: char[], const(char)[] and immutable(char)[]. What
would be the signature of such a function?

This boils down to: "You want to sort an array of T[], U[], or V[],
where the three types are loosely-related, except U is a supertype of
both T and V and the three have the same layout. What would be the
signature of such a function?"
The answer is (to a reasonable approximation) simple:
sort(X)(X[] data) if (is(X : U) && X.sizeof == U.sizeof);
This has nothing to do with qualifiers. Qualified types are distinct,
and obey the classic subtyping and layout rules known since the dawn of
humankind: const is a supertype of mutable and immutable, and they all
have the same layout. Complaining about that equates to complaining
about subtyping.

It can't be sort(const(char)[][]) because it's unsafe to case char[][]
and immutable(char)[][] to that argument type (see
http://d.puremagic.com/issues/show_bug.cgi?id=4251 ).
It can't be sort(const(char[])[]) because you can't actually sort that!
The only good way I found is to use a cast inside the function with the
second signature. Obviously I'm glad there's a workabout, but surely a
cast isn't a good thing.

You'd do the same if you wanted to sort arrays of base and arrays of
derived with the same routine.

Second case:
inout was meant to solve issues with functions that return slices of
inputs. What about a class that is dedicated to the same functionality?
E.g. this works fine:
inout(char)[] half(inout(char)[]);
But what about this:
struct Slicer
{
char[] a;
char[] half();
}
Note that the type of the input (the member 'a') must be the same as the
output of the half method. I don't know how to accomplish this without
templates.

I don't know how to swim with a hand tied to my back, either. The
correct approach is to integrate templates in the discussion and analyze
_that_ context, not the artificial context that precludes templates. D
is not Go.

But as I said in the preface, you shouldn't need templates
for such a simple task.

char and const char are different types. The embedded presupposition is
that they are somewhat similar, the qualifier being some sort of
attribute of the type. That's not the case.

Note that doing this isn't satisfactory:
struct Slicer
{
char[] a;
inout(char)[] half() inout;
}
because there may be other members inside that struct that may need to
remain mutable.

Agreed.

This is very relevant, incidentally, for the planned library
implementation of associative arrays. How would this be implemented when
an associative array is a struct?
inout(char)[] test(inout(char)[])
{
inout(char)[][int] a;
}
It doesn't even compile now (in dmd 2.058).

Associative arrays must be templates.

I don't have any solutions to these problems, incidentally... I think
they are complex, but definitely worthy of having a reasonable solution
that doesn't involve needless (in this case) templates.

Again, we must make templates a part of the setup and discuss what's
going on.
Andrei

Hold them horses. I disagree. You're just saying it, but what's
your basis?

Because some cases (as shown below) trivially work within the
const system, while some closely related ones don't. You're not
going to be able to convince me of a demarcation that requires
some const issues to require templates, and some not.

This boils down to: "You want to sort an array of T[], U[], or
V[], where the three types are loosely-related, except U is a
supertype of both T and V and the three have the same layout.
What would be the signature of such a function?"
The answer is (to a reasonable approximation) simple:
sort(X)(X[] data) if (is(X : U) && X.sizeof == U.sizeof);
This has nothing to do with qualifiers.

Because you removed them. While I agree with the type argument to
a point, qualifiers have more meaning than just arbitrary type
creation: they talk about mutability. The desired function
signature states that the contents of the strings that are in the
array will not be modified, your generic version does not have
that stipulation. I can make up a body for that sort function
which will work for types which fit your description, but fail
for const(char)[], char[] and immutable(char)[].

Second case:
inout was meant to solve issues with functions that return
slices of
inputs. What about a class that is dedicated to the same
functionality?
E.g. this works fine:
inout(char)[] half(inout(char)[]);
But what about this:
struct Slicer
{
char[] a;
char[] half();
}
Note that the type of the input (the member 'a') must be the
same as the
output of the half method. I don't know how to accomplish this
without
templates.

I don't know how to swim with a hand tied to my back, either.
The correct approach is to integrate templates in the
discussion and analyze _that_ context, not the artificial
context that precludes templates. D is not Go.

As much as you might prefer D to be 100% about templates, it is
not, and there is a subset of it which is usable without them.
This subset is the subject of this thread. There is no a priori
reason why the first case should work and second should not
within the confines of the const system.

Hold them horses. I disagree. You're just saying it, but what's your
basis?

Because some cases (as shown below) trivially work within the const
system, while some closely related ones don't. You're not going to be
able to convince me of a demarcation that requires some const issues to
require templates, and some not.

Some cases also work trivially with subtyping, while some closely
related ones don't.

This boils down to: "You want to sort an array of T[], U[], or V[],
where the three types are loosely-related, except U is a supertype of
both T and V and the three have the same layout. What would be the
signature of such a function?"
The answer is (to a reasonable approximation) simple:
sort(X)(X[] data) if (is(X : U) && X.sizeof == U.sizeof);
This has nothing to do with qualifiers.

Because you removed them. While I agree with the type argument to a
point, qualifiers have more meaning than just arbitrary type creation:
they talk about mutability.

That's a given. But that doesn't confer them infinite powers otherwise
inaccessible; you seem to require any flexibility that seems reasonable
within a context, and that's simply put impossible. There is a point
where inout's powers stop (inout can be considered a special case
designed for a few common cases).
I should confess that the subtyping relation (const(T) is a supertype of
both T and immutable(T)) has from day 1 been a guiding design principle
for us, so that shouldn't be taken lightly. There is a relation between
types that is somewhere in between simple subtyping and qualified types:
subtype with layout conservation, i.e. you know that T is a supertype of
U and both T and U have identical layout. For such types we could
accommodate special capabilities in the type system; they'd be
applicable beyond qualified types.

The desired function signature states that
the contents of the strings that are in the array will not be modified,
your generic version does not have that stipulation.
I can make up a
body for that sort function which will work for types which fit your
description, but fail for const(char)[], char[] and immutable(char)[].

I don't know how to swim with a hand tied to my back, either. The
correct approach is to integrate templates in the discussion and
analyze _that_ context, not the artificial context that precludes
templates. D is not Go.

As much as you might prefer D to be 100% about templates,

(let's stay on topic and not make this ad hominem, thanks)

it is not, and
there is a subset of it which is usable without them.

This calls for the obvious answer that there's a subset of D that's
usable without const.

This subset is the
subject of this thread. There is no a priori reason why the first case
should work and second should not within the confines of the const system.

I understand your complaint, but I don't know how to design a type
system that is at the same time reasonably small and simple and allows
all of your examples and some related ones. We have "inout" which is
helpful but at the end of the day a special case for a category of
situations. We can't expect it to do miracles.
Andrei

That's a given. But that doesn't confer them infinite powers
otherwise inaccessible; you seem to require any flexibility
that seems reasonable within a context, and that's simply put
impossible. There is a point where inout's powers stop (inout
can be considered a special case designed for a few common
cases).

And can this not be a special case with a new type too? The issue
is of moving the elements in an array while retaining the const
correctness on the contents of the elements. Something like a
rebindable reference to a constant memory?

Naturally you can't, but that wasn't my point. My point was that
I could do this:
sort(X)(X[] data) if (is(X : const(char)[]) && X.sizeof ==
(const(char)[]).sizeof)
{
data[0][0] = 1;
}
This would compile just fine if you passed it a char[][]. Your
templated function doesn't describe the semantics of the function
(it shouldn't change the elements of the array, just their
order). Is there a way around it? Is it better than casting?

This calls for the obvious answer that there's a subset of D
that's usable without const.

Yes, but it doesn't have these bizzarities.
I like having const correctness in my code, I like the assurance
that my memory isn't being mutated. Once I start using templates,
it seems that that assurance can go out of the window sometimes
because the template system is defined on the level of types, not
on the level of const qualifiers.
-SiegeLord

That's a given. But that doesn't confer them infinite powers
otherwise inaccessible; you seem to require any flexibility
that seems reasonable within a context, and that's simply put
impossible. There is a point where inout's powers stop (inout
can be considered a special case designed for a few common
cases).

And can this not be a special case with a new type too? The issue
is of moving the elements in an array while retaining the const
correctness on the contents of the elements. Something like a
rebindable reference to a constant memory?

If the elements are really const, then you can't move them. Period. Doing so
would violate const. Now, you can have references or pointers to const and
move _those_ around, but then the elements themselves aren't really const. If
you're dealing with objects, you can use std.typecons.Rebindable, though there
is a pull request (which has been around a while and may never get merged in)
which adds syntax for references to const, in which case Rebindable wouldn't
be needed anymore.

This calls for the obvious answer that there's a subset of D
that's usable without const.

Yes, but it doesn't have these bizzarities.
I like having const correctness in my code, I like the assurance
that my memory isn't being mutated. Once I start using templates,
it seems that that assurance can go out of the window sometimes
because the template system is defined on the level of types, not
on the level of const qualifiers.

Templates can't violate const anymore than other code can. Templates don't
strip constness. If you're passing const variables to a templated function,
they're const in the templated function. And if the templated function wants
to guarantee that what you pass in doesn't get altered, then it can mark its
parameters const just like any other function can. Templates do nothing to
screw up const.
- Jonathan M Davis

That's a given. But that doesn't confer them infinite powers otherwise
inaccessible; you seem to require any flexibility that seems
reasonable within a context, and that's simply put impossible. There
is a point where inout's powers stop (inout can be considered a
special case designed for a few common cases).

And can this not be a special case with a new type too? The issue is of
moving the elements in an array while retaining the const correctness on
the contents of the elements. Something like a rebindable reference to a
constant memory?

Naturally you can't, but that wasn't my point. My point was that I could
do this:
sort(X)(X[] data) if (is(X : const(char)[]) && X.sizeof ==
(const(char)[]).sizeof)
{
data[0][0] = 1;
}
This would compile just fine if you passed it a char[][]. Your templated
function doesn't describe the semantics of the function (it shouldn't
change the elements of the array, just their order). Is there a way
around it? Is it better than casting?

As I suggested in my other post, use inout(void) sort(inout(char)[][])
for the semantics you want.

This calls for the obvious answer that there's a subset of D that's
usable without const.

Yes, but it doesn't have these bizzarities.
I like having const correctness in my code, I like the assurance that my
memory isn't being mutated. Once I start using templates, it seems that
that assurance can go out of the window sometimes because the template
system is defined on the level of types, not on the level of const
qualifiers.
-SiegeLord

Firstly, let me preface this... if you use templates to get around the
const system's imperfections, you are admitting that the const system is
broken. Now, on with the program.
My unique experience in using D2 without Phobos lead me to encounter two
cases that show how the D2 const system is just a pain in the behind for
some really reasonable tasks.

inout should solve all these problems. As Timon says, there are bugs with
it. Bugs do not mean the design is not sound.
Also note that you are not unique in that experience, I tried to port
Tango to D2 a long time ago, and the bug report 1961 was a direct result
of trying that porting. In other words, inout was *designed* to allow
Tango to be ported to D2.
-Steve