On Thu, 16 May 2013 11:25:48 +0100, Dicebot <m.stras...@gmail.com> wrote:
On Thursday, 16 May 2013 at 10:13:28 UTC, Regan Heath wrote:
...
I agree that this is a caller responsibility. What leaves me in doubts
is how this responsibility is enforced though. With const nothing in
type system prevents caller to violate that "contract" and mutate data
during function call. Because, well, const does not guarantee that data
is not mutated and thus it is a valid action.
True, it's not enforced. But, that's because the responsibility lies with
the caller, and I think this is a reasonable position to take in these
cases (std.file methods which use but do not retain the argument post-call)
Contrary, immutable is absolutely strict requirement from a function
that caller must take care of passed argument during the function call
or fall into undefined behavior. Explicit usage of "assumeUnique" by
caller is clear sign for a type system "yes, I know what I am doing, I
am responsible". And no accidents possible.
Sure, but it's more verbose, and therefore annoying for the general case
(where the data is not shared).
And..
The issue here is not common (because shared data is not common) /and/
where shared data is used it should already be protected (because that's
the existing pattern).
So that leaves us a very small number of cases which are "broken" and the
solution to all of them is to protect the shared data(*) /not/ to call
assumeUnique. The cases where assumeUnique could be used, so could
const(char).
Basically I think the assumeUnique idea is only useful where const(char)
is useful and const(char) is far nicer.
(*) you cannot even just call idup, because what if the data is in the
process of mutating when you do? You have to protect the shared data with
a mutex or similar.
Regan
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
