On 8/14/16 11:40 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 8/14/16 2:03 PM, Shachar Shemesh wrote:
>>> On 14/08/16 17:07, Andrei Alexandrescu wrote:
>>>> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>>>>> I must confess that I have never heard of this rule in C before
>>>>> encountering it in D.
>>>>
>>>> Which rule?
>>>
>>> The rule that says "ubyte + ubyte = uint".
>>
>> That will not happen. It would break tons of code in subtle ways. You
>> are a competent engineer so you know better than asking for it.
>
> No offense, but that comes across as pretty condescending. I agree that
> changing the integer promotion rules would be very risky, but that's the
> sort of response that seems more likely to offend than to educate or
> convince.

Apologies for the possible offensive interpretation. My statement should be taken at face value - it is indeed not difficult for a programmer to project that changing a fundamental operator typing rule has wide ripples. My larger point is that there's a clear distinction among Shachar's list items: some are things we can work on, and some aren't. Putting them together dilutes the positive impact of the list. -- Andrei

On Friday, 12 August 2016 at 18:04:53 UTC, Andrei Alexandrescu wrote:
> On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
>> On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
>>>
>>> Honestly, I don't think that shared is broken.
>>
>> Yes. It is broken.
>>
>> shared int x;
>> ++x; // error, must use atomicOp.
>> x = x + 1; // OK(!)
>
> How is this broken and how should it behave? -- Andrei

The problem is no one knows if it's broken or not because there is no official documentation saying what shared is supposed to do.

This is all we get

"The shared attribute modifies the type from T to shared(T), the same way as const does."

https://dlang.org/spec/attribute.html

On 14/08/16 21:35, Andrei Alexandrescu wrote:
> I should add that as long as the .di does not import the .d, the
> slowdown due to the computed table will not occur. So the worry is not
> warranted.

I'm not sure the above is true in cases of imports that are not circular for the optimal dis, but are circular when flattened. Then again, but I'm not close enough to the issue to say for sure.

Shachar

On Sunday, 14 August 2016 at 18:03:24 UTC, Shachar Shemesh wrote:
>> 
>>> I must confess that I have never heard of this rule in C before encountering it in D.
>> 
>> Which rule?
>
> The rule that says "ubyte + ubyte = uint".
>
https://www.google.fr/search?q=C+int+promotion+rules&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=xaOxV5vuMpGx8weWtIawAw#q=c+int+promotion+rules+standard

This is so central to understanding the C language that I'm surprized here. There's no forum, FAQ that doesn't mention it.

It's easy to understand conservative programmers, you can even use C++ for web programming but it's waste of time and it won't give you the performance of Dropoid toolkit for Java. Also it's reliability is depends on your skills. Everyone leaving lower level languages other than the internet of things and game development industry. I noticed that, there was no significant progress on software industry for tens of years until higher level languages came out.

On Monday, 15 August 2016 at 13:10:01 UTC, Emre Temelkuran wrote:
> It's easy to understand conservative programmers, you can even use C++ for web programming but it's waste of time and it won't give you the performance of Dropoid toolkit for Java. Also it's reliability is depends on your skills. Everyone leaving lower level languages other than the internet of things and game development industry. I noticed that, there was no significant progress on software industry for tens of years until higher level languages came out.

Do you know vibe.d? http://vibed.org/

On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

>> Also, part of our
>> problems with this is that introspection also does not see refs, which
>> causes the following two functions to report the same signature:
>>
>> void func1(int arg);
>> void func2(ref int arg);
>
> I actually think you can do introspection on any argument to figure
> whether it has "ref".

Yes, it exists. However, I tried std.traits.Parameters but that wasn't it. A colleague reminded us that it's std.traits.ParameterStorageClassTuple:

  http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple

Ali

Well there are some things I feel could be improved, a lot of the things are really just minor but what is a deal breaker for me mostly is the compilers. The GCC and Clang implementations are really far behind in terms of the version, so they are missing a lot of features. A lot of the features that I'd want to use D for. In the download section it also says "good optimization" but it honestly isn't. I rewrote a small portion for one of my projects to test out D but looking at the assembly a lot of it was questionable. I'd say DMD probably produced the best assembly but then there's the problem that it doesn't support MMX instructions. Even on 64-bit it still uses the FPU, which I can't really use. The FPU isn't consistent enough for simulations that run on separate computers and different OSs that need to be synced through a network.

Anyways for some more minor things. I really don't like __gshared, why couldn't it just be named "gshared" instead. Don't like how that naming convention is used in C/C++ either but I feel here in D it is completely out of place. Nothing else uses a preceding "__" and from the documentation it looks like it's made to stand out cause it shouldn't be used. But it is used a lot, and it wouldn't be possible to do certain things without it. I forget but the dynamic library loader for D, derelict, is one such case.

There's no "const T&" equivalent in D. Basically constant variables need to be copied and non-constant variables can be passed with the use of "ref". So you need to write two different functions that in essence do the same thing. One way around the code duplication is using templates so that it auto generates these variants for you, but then there's code bloat cause each parameter could then be a copy or a "ref". This leads to a lot of extra copies, depending on the object and it's size it might not be desirable. It thus limits code where you could do a one line operation like: "someObject.process(otherObject.generateLargeConstantObject());". In this case there will be an extra copy made, and currently none of compilers are able to optimize it out. It seems like it is possible for the compiler to be able to optimize it so no copies are made but that's not the case currently which goes back my main argument I guess. I can see the value in not having a "const&" but the current implementation is flawed.

http://ideone.com/INGSsZ

Garbage collector is in a few libraries as well. I think the only problem I had with that is that the std.range library has severely reduced functionality when using static arrays.

I think there was more but it was a while since I used D and don't recall. There are significant improvements to D over C++ that I do love, really want to be able to use it. Whenever I run into an issue with C++ I just think about D and how I could have solved that problem easily.

On Sunday, 14 August 2016 at 18:45:06 UTC, Walter Bright wrote:
> This rule was retained for D to make it easier to translate code from C/C++ to D. Changing the rule could result in subtle and invisible bugs for such translations and for C/C++ programmers who are so used to the integral promotion rules that they aren't even really aware of reliance upon them.
>
> The reason C/C++ programmers, even experienced ones, are often unaware of this rule is there is another rule, implicit narrowing, so:
>
>     byte = byte + byte;
>
> compiles without complaint. The trouble comes when byte has a value, say, 255, and the sum is 510. The assignment silently chops it to byte size, and 254 is stored in the result.
>
> For D, we decided that silently converting 510 to 254 would not be acceptable. Hence an explicit cast would be required,
>
>     byte = cast(byte)(byte + byte);

Well you could say the same for the same for int. Why isn't "int + int = long"? Right now it is following the rule "int + int = int". Maybe cause the values aren't as small but I could argue the same thing. If we add 2147483647 with 2147483647, the value stored is -2. Under the same sort of thought, you probably wouldn't find that acceptable either correct? At some point you are going to run out of types that have larger storage. What is "cent + cent" going to have as a larger type? At some point you just have to accept that you are working with a finite set of numbers. For D the compromise happens with the type int. C/C++ just accepts that and maintains consistency rather than flip floping at an arbitrary type.

Hei John, I read over the first part of your message and it seems that same information you got is quite outdated:

On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
> Well there are some things I feel could be improved, a lot of the things are really just minor but what is a deal breaker for me mostly is the compilers. The GCC and Clang implementations are really far behind in terms of the version, so they are missing a lot of features. A lot of the features that I'd want to use D for.

That's not true for LDC - it's on par with the latest DMD version since a while now. It might be that the version shipped with your Linux distribution is a bit outdated.

http://forum.dlang.org/post/uxupejapglpeokaiqqjg@forum.dlang.org


> In the download section it also says "good optimization" but it honestly isn't. I rewrote a small portion for one of my projects to test out D but looking at the assembly a lot of it was questionable. I'd say DMD probably produced the best assembly but then there's the problem that it doesn't support MMX instructions.

That's weird - LDC allows great optimization, see e.g. these two benchmarks:

https://github.com/kostya/benchmarks
http://forum.dlang.org/post/zxkkjezakirlfepndjxk@forum.dlang.org

> Even on 64-bit it still uses the FPU, which I can't really use. The FPU isn't consistent enough for simulations that run on separate computers and different OSs that need to be synced through a network.

Inconsistent FP math is a known issue, but most likely a fusedMath pragma will be added soon:

http://forum.dlang.org/post/hjaiavlfkoamenidomsa@forum.dlang.org
https://github.com/ldc-developers/ldc/issues/1669

> Anyways for some more minor things. I really don't like __gshared, why couldn't it just be named "gshared" instead. Don't like how that naming convention is used in C/C++ either but I feel here in D it is completely out of place. Nothing else uses a preceding "__" and from the documentation it looks like it's made to stand out cause it shouldn't be used. But it is used a lot, and it wouldn't be possible to do certain things without it. I forget but the dynamic library loader for D, derelict, is one such case.

Yep you are correct about the motivation: __gshared got its ugly name to remind
the programmer about the dangerous world he wades into.
There are usually safer & more elegant ways, e.g.:

http://tour.dlang.io/tour/en/multithreading/std-parallelism
http://tour.dlang.io/tour/en/multithreading/synchronization-sharing
http://tour.dlang.io/tour/en/multithreading/message-passing

On 08/19/2016 12:50 AM, John Smith wrote:
> Well there are some things I feel could be improved, a lot of the things
> are really just minor but what is a deal breaker for me mostly is the
> compilers. The GCC and Clang implementations are really far behind in
> terms of the version, so they are missing a lot of features. A lot of
> the features that I'd want to use D for.

LDC has been catching up quite nicely. LDC 1.0.0 (current release) is at front-end 2.070, and 1.1.0 (beta) is at 2.071 which matches the current DMD release.

https://github.com/ldc-developers/ldc/releases

> In the download section it also
> says "good optimization" but it honestly isn't. I rewrote a small
> portion for one of my projects to test out D but looking at the assembly
> a lot of it was questionable. I'd say DMD probably produced the best
> assembly but then there's the problem that it doesn't support MMX
> instructions.

I'm not very knowledgeable on optimized machine code, but as far I know, LDC/GDC usually produce significantly faster binaries than DMD. So when DMD comes out ahead, that's not typical. Might be an outlier.

[...]
> Anyways for some more minor things. I really don't like __gshared, why
> couldn't it just be named "gshared" instead. Don't like how that naming
> convention is used in C/C++ either but I feel here in D it is completely
> out of place. Nothing else uses a preceding "__" and from the
> documentation it looks like it's made to stand out cause it shouldn't be
> used.

That's exactly it. `__gshared` has a weird name because `shared` should generally be used instead. `__gshared` throws thread-safety out the window, while `shared` is supposed to at least make sure that the shared-ness is visible to the programmer.

> But it is used a lot, and it wouldn't be possible to do certain
> things without it. I forget but the dynamic library loader for D,
> derelict, is one such case.

Those certain things should be relatively rare low-level tasks. When `__gshared` is used more than `shared`, then `shared` may (currently) be failing its goals. Of course, a low-level project like Derelict may just have more use for `__gshared`.

> There's no "const T&" equivalent in D. Basically constant variables need
> to be copied and non-constant variables can be passed with the use of
> "ref". So you need to write two different functions that in essence do
> the same thing.

You can pass const variables per ref: void foo(ref const int bar) {}

What you can't do is pass rvalues in such a parameter. That's what the other function/overload is needed for. That doesn't mean that everything is just fine as it is.

[...]
> Garbage collector is in a few libraries as well. I think the only
> problem I had with that is that the std.range library has severely
> reduced functionality when using static arrays.

You may be aware of this, but you can slice a T[n] to get a T[] which is a range.

[...]
> Well you could say the same for the same for int. Why isn't "int + int =
> long"? Right now it is following the rule "int + int = int". Maybe cause
> the values aren't as small but I could argue the same thing. If we add
> 2147483647 with 2147483647, the value stored is -2. Under the same sort
> of thought, you probably wouldn't find that acceptable either correct?
> At some point you are going to run out of types that have larger
> storage. What is "cent + cent" going to have as a larger type? At some
> point you just have to accept that you are working with a finite set of
> numbers. For D the compromise happens with the type int. C/C++ just
> accepts that and maintains consistency rather than flip floping at an
> arbitrary type.

I don't think that C "just accepts that". It still promotes a sum of smaller types to int.

Observe:

----
#include<stdio.h>

int main()
{
    unsigned char a = 255;

    printf("%d\n", (a + a) / 2); /* 255 */
    printf("%d\n", (unsigned char)(a + a) / 2); /* 127 */

    return 0;
}
----

If `a + a` were an unsigned char, we'd expect the two outputs to be the same.

The difference between D and C is that C has implicit narrowing. I.e., it lets you assign an int to a char just like that, throwing away the high bits. D requires a cast for it.

So, why is int the go-to type? I can't answer with authority, but for D I think it's just because that's what C does.