When I add the directive:

pragma(lib, "foo");

to a file called "bar.d" and then do:

dmd -c bar.d

does the object file bar.o or bar.obj contain a directive that reflects the pragma, or does pragma(lib) only work when compiling and linking in one step, e.g. dmd bar.d?

On 27/08/2011 16:59, dsimcha wrote:
> When I add the directive:
>
> pragma(lib, "foo");
>
> to a file called "bar.d" and then do:
>
> dmd -c bar.d
>
> does the object file bar.o or bar.obj contain a directive that reflects
> the pragma, or does pragma(lib) only work when compiling and linking in
> one step, e.g. dmd bar.d?

pragma(lib) only works with one step compilation - it's useless if you want one-at-a-time compilation, hence why rebuild and other tools had pragma(link).

-- 
Robert
http://octarineparrot.com/

After having used the D 2.0 programming language for a year now and having completed 3 projects with it, I wrote a small article about the problems I had with the D 2.0 programming language and what suggestions I have to improve it.

http://3d.benjamin-thaut.de/?p=18

Comments and criticism welcome

-- 
Kind Regards
Benjamin Thaut

On 8/27/2011 1:14 PM, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and
> having completed 3 projects with it, I wrote a small article about the
> problems I had with the D 2.0 programming language and what suggestions
> I have to improve it.
>
> http://3d.benjamin-thaut.de/?p=18
>
> Comments and criticism welcome
>

Excellent article.  I like the constructive criticism without the "D will never be better than C++, Walter Bright is an idiot, I will never use a GC language, D is slow on one benchmark therefore it is poorly designed and will be slow forever" attitude.

Some of the things you mention are definitely bugs. (I'd call emplace requiring exact c'tor arguments, TID not supporting shared, the thread-local storage/GC issue, and maybe no function overloading with template parameters bugs.  The TLS issue is already known.)  These have a lot higher a probability of getting fixed if you file them as bug reports (see http://d.puremagic.com/issues/ ).  Better yet, if yo know how to fix it, you can submit a pull request to the DProgrammingLanguage Github page.

Other things you mention are design decisions that are the result of carefully considered tradeoffs.  These include structs not having an identity, lack of implicit c'tors, and shared.  These are tradeoffs that may not be the best for your situation, but are not unforced errors.

As far as assert, maybe there should be a compiler switch that makes all asserts behave the way assert(0) does in release mode:  Simply issue the HLT instruction and use a debugger to figure out what went wrong. However, I think the current behavior of assert is the right default behavior because it gives clear hints as to what went wrong (and a stack trace on newer releases) even if you're not running in a debugger.

Associative array invariance may be fixable now using reference counting.  This issue has been in the back of my mind for a long time. Thanks for bringing it back to the front, and maybe it's worth fixing.

On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and having completed 3 projects with it, I wrote a small article about the problems I had with the D 2.0 programming language and what suggestions I have to improve it.
>
> http://3d.benjamin-thaut.de/?p=18
>
> Comments and criticism welcome
>
> "This transitiv[it]y basically kills you everywhere."

I feel like you hit the nail on the head. I feel the same way about const.

Transitivity is beautiful on the outside, but I can never actually get it working, so I just make everything non-const. I have to sometimes do this even in Phobos itself, because the compiler complains about something random caused by transitivity.
I also fail to see what /problem/ it's trying to solve. The DigitalMars website simply states:

"With transitivity, there is no way to have a const pointer to mutable int."

But... so what? Maybe it should actually explain the benefit, since I can't figure it out on my own. (The related discussion on "head-const" and "tail-const" seems completely irrelevant to the topic."

C++'s non-transitivity seems to be quite type-safe, even if unintuitive to the beginner (which I don't think it is). I *never* ran into issues with it.


*On the bright side*, I LOVE immutable. It's one of the best features of D, IMO. (Or at least it would be, if only it /wasn't/ transitive.) I don't like the way C++ mixes the idea of "this never mutates" versus "YOU can't mutate this object", and I feel like D was really smart in making the distinction between the two.


Related suggestion: All methods that return /new/ strings should return *mutable* arrays. There's really no reason (that I can think of) to not do this: if you see something returning a mutable array, you _know_ it's a new array (unless otherwise documented), so you _know_ it's safe to cast it to immutable if needed. It doesn't work the other way around, though.

"Mehrdad" <wfunction@hotmail.com> wrote in message news:j3beu2$25a8$1@digitalmars.com...
> Related suggestion: All methods that return /new/ strings should return *mutable* arrays. There's really no reason (that I can think of) to not do this: if you see something returning a mutable array, you _know_ it's a new array (unless otherwise documented), so you _know_ it's safe to cast it to immutable if needed. It doesn't work the other way around, though.

Since a few days ago, mutable strings returned from strongly pure functions can be implicitly converted to immutable ones, so a cast won't be needed any more.

On 8/27/2011 3:47 PM, Daniel Murphy wrote:
> "Mehrdad"<wfunction@hotmail.com>  wrote in message
> news:j3beu2$25a8$1@digitalmars.com...
>> Related suggestion: All methods that return /new/ strings should return
>> *mutable* arrays. There's really no reason (that I can think of) to not do
>> this: if you see something returning a mutable array, you _know_ it's a
>> new array (unless otherwise documented), so you _know_ it's safe to cast
>> it to immutable if needed. It doesn't work the other way around, though.
>
> Since a few days ago, mutable strings returned from strongly pure functions
> can be implicitly converted to immutable ones, so a cast won't be needed any
> more.
>
>

Does the same apply to all arrays of primitives?

Mehrdad:

> "With transitivity, there is no way to have a const pointer to mutable int."
> 
> But... so what? Maybe it should actually explain the benefit, since I can't figure it out on my own.

D wants both mutable data and (strongly) pure functions. How do you bridge such two worlds? If you have mutable data and you want to pass it to a pure function, you need a way to say this data structure will not change, nor any data it refers to. I think the D transitive const is the simpler way to do this.


> C++'s non-transitivity seems to be quite type-safe, even if unintuitive to the beginner (which I don't think it is). I *never* ran into issues with it.

The C++ compiler doesn't offer means to enforce pure functions.

In my opinion it's possible to add a C++-style const to D too, but this further increases the complexity of D, it cannot be used for purity, and it can't be used for compiler optimizations, you are allowed to safely cast it away when you want, it's just a convention, as in C++. But maybe it's useful anyway because most times you try to mutate the first level of a data structure, and such shallow const is enough to catch such unintentional mutation bug.

Bye,
bearophile

dsimcha:

>Some of the things you mention are definitely bugs. (I'd call emplace requiring exact c'tor arguments, TID not supporting shared, the thread-local storage/GC issue, and maybe no function overloading with template parameters bugs.  The TLS issue is already known.)  These have a lot higher a probability of getting fixed if you file them as bug reports<

Otherwise, are you able and willing to add those to Bugzilla yourself?

Bye,
bearophile

"dsimcha" <dsimcha@yahoo.com> wrote in message news:j3bk94$2e72$1@digitalmars.com...
>>
>> Since a few days ago, mutable strings returned from strongly pure
>> functions
>> can be implicitly converted to immutable ones, so a cast won't be needed
>> any
>> more.
>
> Does the same apply to all arrays of primitives?

To all types.  Arrays, AAs, classes etc.