• Kagamin <spam here.lot> Aug 12 2010
• Kagamin <spam here.lot> Aug 12 2010
• Jonathan M Davis <jmdavisprog gmail.com> Aug 12 2010
• Kagamin <spam here.lot> Aug 13 2010
• Michel Fortin <michel.fortin michelf.com> Aug 13 2010

Kagamin <spam here.lot> writes:

Jonathan M Davis Wrote:

 The lack of a mutable qualifier seems like it could be 
 another big problem, but I haven't yet written enough code in D to run into
that 
 issue (still I'm sure I'll run into it eventually and be highly annoyed - it's 
 just needed too often in C++ for me not to be happy about it missing in D).


I've run into it - Exception, generating its error message on demand and
caching it in const toString. I think, it's no problem no not have mutable
qualifier, because I don't want it often. And you can create a function like
void cacheValue!(T)(ref const T storage, T value);

 I'm a huge fan of const in C++, and I _really_ want to be able to use it in D 
 (the lack of const in D1 is one of the big reasons that chose to use D2 even 
 when it was new rather than mess with D1),


Same here :)
I think, const can be made to work.

 but the bugs related to it have made 
 it difficult, and I just haven't written very much large stuff in D - and
that's 
 where you really need it.


How I'm working on a large project written in C#. C# has only D1 const system.
Here I've seen no bugs caused by all data beign mutable. Even with public
mutable fields. Usually bugs we have are unimplemented logic, incorrectly
implemented logic, exceptions swallowing, undocumented external unmanaged (and
buggy) library, that wants nice parameters. And bad design, oh... desing is
baaaad.

Kagamin <spam here.lot> writes:

Kagamin Wrote:

 Now I'm working on a large project written in C#. C# has only D1 const system.
Here I've seen no bugs caused by all data beign mutable. Even with public
mutable fields. Usually bugs we have are unimplemented logic, incorrectly
implemented logic, exceptions swallowing, undocumented external unmanaged (and
buggy) library, that wants nice parameters. And bad design, oh... desing is
baaaad.


Ah, and many casts to object and from object. This caused many bugs. That's why
I will always advocate for throwing cast, it's unacceptable that D by default
provides bug-prone behavior. I will never accept this.

Jonathan M Davis <jmdavisprog gmail.com> writes:

On Thursday 12 August 2010 22:10:20 Kagamin wrote:
 Jonathan M Davis Wrote:
 but the bugs related to it have made
 it difficult, and I just haven't written very much large stuff in D - and
 that's where you really need it.


 How I'm working on a large project written in C#. C# has only D1 const
 system. Here I've seen no bugs caused by all data beign mutable. Even with
 public mutable fields. Usually bugs we have are unimplemented logic,
 incorrectly implemented logic, exceptions swallowing, undocumented
 external unmanaged (and buggy) library, that wants nice parameters. And
 bad design, oh... desing is baaaad.


Of course, you can write large projects without const. Many other languages 
which are heavily used lack const. However, there is great benefit in having 
const, and you're most likely to derive that benefit from large projects where 
things are much more complex then you are with small projects where you can 
probably keep most of it in your head and/or you're the only one working on it. 
You can obviously do lots of quality programs without const, but having it is a 
big plus.

- Jonathan M Davis

Kagamin <spam here.lot> writes:

Jonathan M Davis Wrote:

 You can obviously do lots of quality programs without const, but having it is
a 
 big plus.


We do have evil developers that write evil code, my point is that nevertheless
the lack of constness didn't cause bugs. The constness in D2 did help me only
to comply with OS interface when things, that should be "in", are not const.

Michel Fortin <michel.fortin michelf.com> writes:

On 2010-08-13 01:10:20 -0400, Kagamin <spam here.lot> said:

 Jonathan M Davis Wrote:
 
 The lack of a mutable qualifier seems like it could be
 another big problem, but I haven't yet written enough code in D to run 
 into that
 issue (still I'm sure I'll run into it eventually and be highly annoyed - it's
 just needed too often in C++ for me not to be happy about it missing in D).


 I've run into it - Exception, generating its error message on demand 
 and caching it in const toString. I think, it's no problem no not have 
 mutable qualifier, because I don't want it often. And you can create a 
 function like void cacheValue!(T)(ref const T storage, T value);


If it does that then it's not thread-safe. If you make an immutable 
exception and attempt to call toString from multiple threads, then you 
create a race condition. Using a write barrier before setting the 
mutable variable we could make the race inconsequential (because in 
this specific case generating and assigning the same string twice won't 
create any problem), but without this you have a race and could get an 
incomplete string from one of the threads.

You might never run into this problem with an Exception, but this is 
certainly not a safe pattern.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/