const debacle
Sean Kelly
sean at invisibleduck.org
Fri Mar 21 11:04:25 PDT 2008
== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> This issue was just brought to my attention, and I wonder if the other
> const-proponents have a good solution for this. This is going to be very
> tough to deal with.
> How do you declare a function that takes an array, is not allowed to change
> the array, but returns a slice into the argument array, and the return type
> matches the argument type.
> For example, if I pass a mutable array to this function, I want it to pass
> me back a mutable slice into the array, but I also want a guarantee that the
> function will not modify the array. I can't declare the argument is const
> because then the return value must also be const, as it is a slice of the
> original array.
> How does one solve this problem?
Use overloaded functions. In theory, I think this should work:
T[] func(T)( T[] buf ) { ... }
const T[] func(T)( const T[] buf ) { ... }
invariant T[] func(T)( invariant T[] buf ) { ... }
Even if D doesn't overload on const-ness (I seem to recall that it doesn't right now), I think the above
set of functions won't conflict because one will be more specialized than the other, based on the
supplied type. However, this aspect of D is fairly primitive so it's somewhat of a shot in the dark.
Weren't templates in 2.0 eventually supposed to get some way to learn the const-ness of a parameter? I
seem to recall that from Walter and Andrei's conference presentation.
Sean
More information about the Digitalmars-d
mailing list