On Feb 7, 2012, at 3:55 PM, Artur Skawina wrote:
> On 02/08/12 00:32, Sean Kelly wrote:
>> [...] the transitivity of shared can still make for some weirdness at the
>> implementation level. For example, if I have:
>>
>> class Thread {
>> pthread_t p;
>> shared void detach() {
>> pthread_detach(p);
>> }
>> }
>>
>> Building this yields:
>>
>> Error: function core.sys.posix.pthread.pthread_detach (_opaque_pthread_t*)
>> is not callable using argument types (shared(_opaque_pthread_t*))
>> Error: cannot implicitly convert expression (this.p) of type
>> shared(_opaque_pthread_t*) to _opaque_pthread_t*
>>
>> So I either need to speculatively update a bunch of system API calls to add
>> a 'shared' qualifier to everything I think will always be used in a shared
>> context, or explicitly cast away shared when actually passing these
>> variables to their associated API routines. Neither option is appealing, so
>> again I haven't done anything regarding shared.
>
> An overload would work, right?
>
> class Thread {
> pthread_t p;
> shared void detach() {
> pthread_detach(p);
> }
> void detach() {
> pthread_detach(p);
> }
> }
The shared call still won't work because pthread_detach accepts a pthread_t,
not a shared(pthread_t). It might work if pthread_t weren't a pointer type,
but that obviously can't be safely assumed. This is a tiny bit like when
static arrays were changed to be passed by value. This applies to the C API as
well, regardless of the fact that C has no notion of passing arrays by value.
But at least in that case the type of the parameter didn't change based on the
calling context.
