On Thu, 16 May 2013 12:06:18 +0100, Dicebot <m.stras...@gmail.com> wrote:
On Thursday, 16 May 2013 at 10:41:51 UTC, Regan Heath wrote:
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)
You see, if it is not enforced, than no one has any real responsibility.
Multi-threading based on convention has been used quite a lot in C/C++
according to my experience it sucks. D developers has done a lot of work
in pursuing type system that is aware of multi-threading and can make
certain enforcements / provide guarantees. It makes no sense to stop in
the midway.
You're missing my main point.
The number of actually "broken" cases are small and the solution is always
always always to protect the shared data. assumeUnique cannot help in
these cases, so the caller ends up calling idup. The caller cannot safely
call idup unless the shared data is protected. So, all roads lead to -
protect the shared data. Given that, const(char) is 100% perfectly safe.
One of D slogans I remember was "Safe by default, efficient when
needed". This is exactly one of such cases. Any type contract should be
stated explicitly. Everywhere.
As shown above, just using immutable(char) does not ensure it is safe.
The caller could use assumeUnique mistakenly, or call idup without
protecting the shared state, both are subtle bugs and the only solution is
- protect the shared data.
Any impression of complete safety from immutable(char) is therefore false.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
