The "no gc" crowd
H. S. Teoh
hsteoh at quickfur.ath.cx
Thu Oct 10 11:28:57 PDT 2013
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:
BigInt x = 123;
BigInt y = x; // creates an alias to x's data.
Allowing implicit conversion to unqual would break immutability:
immutable(BigInt) x = 123;
const(BigInt) sneaky = x; // sneaky aliases x
BigInt y = sneaky; // now y aliases sneaky, which aliases x (oops)
Of course, the way BigInt is implemented, any operation on it causes new
data to be created (essentially it behaves like a copy-on-write type),
so it's not as though you can directly modify immutable this way, but
it breaks the type system and opens up possible loopholes.
What you need to do is to use inout for functions that need to handle
both built-in ints and BigInts, e.g.:
inout(Num) abs(Num)(inout(Num) x) {
return (x >= 0) ? x : -x;
}
This *should* work (I think -- I didn't check :-P).
Arguably, a *lot* of generic code involving numerical operations is
broken, because they assume built-in types' behaviour of being
implicitly convertible to/from immutable (due to being value types).
I don't know about shared, though. Last I heard, shared was one big mess
so I'm not even going to touch it.
T
--
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
More information about the Digitalmars-d
mailing list