Just a snapshot of the way things are right now - I'd like to get a real beta out before Dcon.

http://ftp.digitalmars.com/dmd2beta.zip
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 04/28/2013 04:11 AM, Walter Bright wrote:
> Just a snapshot of the way things are right now - I'd like to get a real
> beta out before Dcon.
>
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Why is the shared version of phobos named differently than the static version?

-- 
Mike Wey
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/28/2013 8:00 AM, Mike Wey wrote:
>
>>
>
> Why is the shared version of phobos named differently than the static version?
>

I couldn't get the linker to reliably pick one or the other unless they had different base names.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I noticed that the following doesn't work anymore:

---
class Test {
    this()
    {
        // ...
    }
}

void main()
{
    auto test = new shared Test; // Error: non-shared method
shared_obj.Test.this is not callable using a shared object
    //auto test cast(shared)new Text; // still works, but ugly and with
dangerous semantics
}
---

Is there a compelling reason for this or is it just an artifact of another change? It looks like http://d.puremagic.com/issues/show_bug.cgi?id=9974 describes this, too, but the fix doesn't seem to have changed anything regarding the original issue as far as I can see.

This one hurts a lot because it (again) destroys the only way to use shared objects in a generally acceptable way (i.e. without coding everything twice, once with "shared" and once without, and without casts everywhere):

1. Write the class without explicit "shared" support
2. Creates shared objects where needed using "new shared ClassName"
3. Use a special "lock()" function that locks the object and safely
casts away shared during the lock

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 04/28/2013 09:07 PM, Walter Bright wrote:
>
> On 4/28/2013 8:00 AM, Mike Wey wrote:
>>
>>>
>>
>> Why is the shared version of phobos named differently than the static
>> version?
>>
>
> I couldn't get the linker to reliably pick one or the other unless they
> had different base names.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Usually you would use the -Bstatic and the -Bdynamic switches which whould tell the linker: the libraries passed after this switch should be linked statically or dynamically.

But if it's just for on library you could use -l:libphobos2.a or -l:libphobos2.so to tell the linker which version to link with.

But i don't know how the user would specify this when compiling something with dmd, with the current setup you can pass -defaultlib=phobos2so to dynamically link with phobos.

-- 
Mike Wey
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/29/2013 11:21 AM, Mike Wey wrote:
>
> Usually you would use the -Bstatic and the -Bdynamic switches which whould tell the linker: the libraries passed after this switch should be linked statically or dynamically.

I found the documentation for those switches to be pretty much nonexistent, leading me loathe to rely on them.

>
> But if it's just for on library you could use -l:libphobos2.a or -l:libphobos2.so to tell the linker which version to link with.

The linker rejected that, it wants a name without the "lib" prefix and ".a" suffix.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 04/29/2013 08:51 PM, Walter Bright wrote:
>> But if it's just for on library you could use -l:libphobos2.a or
>> -l:libphobos2.so to tell the linker which version to link with.
>
> The linker rejected that, it wants a name without the "lib" prefix and
> ".a" suffix.
>

You should be able to specify the complete library name if you prefix it with a colon. This option was added to ld in version 2.18 which was released in 2007.

-- 
Mike Wey
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/29/2013 1:45 PM, Mike Wey wrote:
> On 04/29/2013 08:51 PM, Walter Bright wrote:
>>> But if it's just for on library you could use -l:libphobos2.a or
>>> -l:libphobos2.so to tell the linker which version to link with.
>>
>> The linker rejected that, it wants a name without the "lib" prefix and
>> ".a" suffix.
>>
>
> You should be able to specify the complete library name if you prefix it with a colon. This option was added to ld in version 2.18 which was released in 2007.
>

I didn't know that. I'll give it a try.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2013/4/29 Sönke Ludwig <sludwig@outerproduct.org>

> I noticed that the following doesn't work anymore:
>
> ---
> class Test {
>     this()
>     {
>         // ...
>     }
> }
>
> void main()
> {
>     auto test = new shared Test; // Error: non-shared method
> shared_obj.Test.this is not callable using a shared object
>     //auto test cast(shared)new Text; // still works, but ugly and with
> dangerous semantics
> }
> ---
>

First of all, this is a new feature from 2.063 - qualified constructor
support.
In the definition of the class Test, mutable constructor this() could
construct only non-shared objects. Then you cannot create shared object by
using it.


> This one hurts a lot because it (again) destroys the only way to use shared objects in a generally acceptable way (i.e. without coding everything twice, once with "shared" and once without, and without casts everywhere):
>
> 1. Write the class without explicit "shared" support
> 2. Creates shared objects where needed using "new shared ClassName"
> 3. Use a special "lock()" function that locks the object and safely
> casts away shared during the lock


One proper way is adding shared constructor overload. Now it would be
correctly selected for the construction.
class Test {
    this() {}   // for non-shared mutable construction
    this() shared {}    // for shared mutable object construction
}
new Test();   // this() is used
new shared Test();  // this() shared is used

One another way is make the constructor 'pure'. If a pure constructor satisfies some conditions, it would become to 'unique constructor'.

class Test {
    this() pure {}   //
}
new Test();   // this() pure is used
new shared Test();  // this() pure is used!

In default, this() is used for non-shared mutable object.
But pure attribute enforces that the constructed object does not hold any
"non-shared mutable global data" implicitly, then compiler can guarantee
that the constructed object is unique.
Unique object can be convertible to any qualifier, then implicit conversion
to shared is accepted.

Thanks.

Kenji Hara

Am 30.04.2013 02:42, schrieb Kenji Hara:
> First of all, this is a new feature from 2.063 - qualified constructor
> support.
> In the definition of the class Test, mutable constructor this() could
> construct only non-shared objects. Then you cannot create shared
> object by using it.
> (...)
> One proper way is adding shared constructor overload. Now it would be
> correctly selected for the construction.
> (...)
> One another way is make the constructor 'pure'. If a pure constructor
> satisfies some conditions, it would become to 'unique constructor'.
> (...)
> In default, this() is used for non-shared mutable object.
> But pure attribute enforces that the constructed object does not hold
> any "non-shared mutable global data" implicitly, then compiler can
> guarantee that the constructed object is unique.
> Unique object can be convertible to any qualifier, then implicit
> conversion to shared is accepted.
>

Thank you for the explanation! Disallowing global data makes a lot of sense for constructing immutable objects. But for shared objects, shouldn't the compiler rather just disallow accessing any non-shared fields (and methods) on a shared object?

If that is enforced (and that needs to be enforced anyway AFAICS), there should be no way to accidentally reference unshared global data from shared code. Thus, allowing to use unshared constructors for shared objects should not result in unsafe code and can be allowed. The only thing would be that the freshly initialized data is not accessible after construction - but this is actually very useful/necessary to make the lock()-scenario safe.

By the way (not specifically targeted at you, Kenji), while I reworked parts of my code to be "pure", it became very obvious that the direction we are heading becomes really involved without pure by default. Everything is littered with "pure" annotations and many of the most important parts of Phobos are impure (e.g. Appender should be able to be weakly pure), to the point that it seems impractical to use in a larger setting. If there was something like "@impure", it would be possible to put a "pure:" at the top of each module and only explicitly handle the impure code blocks, making it far more manageable without breaking backwards compatibility.

I don't remember discussions about this, but I think this needs to get priority as "pure" feels more and more self-contradictory in that it is an opt-in feature (and thus typically only used when necessary), but at the same time is required for all kinds of basic language functionality (now also for unique expressions). If it is vital for so many things, it should really be the default (of course not possible without breaking backwards compatibility), or at least be able to come close to being the default.

Best regards,
Sönke
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta