The "no gc" crowd

Simen Kjaeraas simen.kjaras at gmail.com
Thu Oct 10 17:30:21 PDT 2013


On 2013-10-10, 20:28, H. S. Teoh wrote:

> On Thu, Oct 10, 2013 at 07:36:06PM +0200, Joseph Rushton Wakeling wrote:
>> On 10/10/13 19:31, Jonathan M Davis wrote:
>> >I'm honestly surprised that Andrei is rejecting the idea of casting
>> >to/from shared or immutable being normal given how it's required by
>> >our current concurrency model. And changing that would be a _big_
>> >change.
>>
>> I'm starting to incline towards the view that type qualifications of
>> _any_ kind become problematic once you start working with any types
>> other than built-in, and not just in the context of concurrency.
>> See e.g.:
>> http://d.puremagic.com/issues/show_bug.cgi?id=11148
>> http://d.puremagic.com/issues/show_bug.cgi?id=11188
>>
>> I'd really appreciate advice on how to handle issues like these,
>> because it's becoming a serious obstacle to my work on std.rational.
>
> I left some comments on these bugs. Basically, BigInt should not be
> implicitly castable from const/immutable to unqual, because unlike the
> built-in types, it's *not* a value type:
[snip]
> What you need to do is to use inout for functions that need to handle
> both built-in ints and BigInts, e.g.:
[snip]

Here's a COW reference type that I can easily pass to a function
requiring a mutable version of the type:

   struct S {
     immutable(int)[] arr;
   }

And usage:

   void foo(S s) {}

   void main() {
     const S s;
     foo(s);
   }


This compiles and works beautifully. Of course, no actual COW is
happening here, but COW is what the type system says has to happen.
Another example COW type:

   string;

Now, my point here is that BigInt could easily use an immutable
buffer internally, as long as it's purely COW. It could, and it should.
If it did, we would not be having this discussion, as bugs #11148 and
#11188 would not exist. Inventing rules like 'you should use inout'
does not help - it's obscuring the problem.

TLDR: Do not use inout(T). Fix BigInt.

-- 
   Simen


More information about the Digitalmars-d mailing list