On Wed, 12 Jun 2013 12:18:50 -0400, deadalnix <deadal...@gmail.com> wrote:
I knew you'll have interesting feddback.
On Wednesday, 12 June 2013 at 15:33:13 UTC, Steven Schveighoffer wrote:
The one problem I see here is the case where you want to have Array
mutate its data.
I admit that this won't solve the issue. But I don't know if this is an
issue to be fair.
To avoid escaping pointers to your elements. This is especially important
if you have total control over allocation of your elements.
I would have to think about it more, but I think there is another
fundamental problem with this. It feels like you could be converting
const two levels deep, which is not allowed.
For example, let's say Array makes ptr and length private overloads
opIndex AND opIndexAssign to prevent taking the the address of its data.
I'm not sure what is the use case. But that is clearly impossible with
the solution I proposed.
Another issue here is, what if you don't want Array to be a template?
That is, you want:
struct IntArray {
size_t length;
int *ptr;
}
How do you make this tail-const-able?
By making it a template. I'm also not sure what is the use case here,
but still this is a limitation.
The use case:
class Container(T)
{
struct range
{
size_t length;
T* ptr;
}
}
Which I use for all dcollections containers.
Yes, I could introduce it like this:
struct range(inout U) if(is(U == T))
{
size_t length;
U *ptr;
}
but it feels unnecessary. I also find the usage for this solution clumsy.
It's a very good start, and very close to the solution I have. I'm
going to finish my article and post it hopefully next week.
Could you give a quick executive summary ?
I am hesitant to publicly announce it before releasing the article :) I
don't want preconceptions for when people read it. I will send you an
email.
-Steve
