On 21/08/16 12:47, ag0aep6g wrote:
> On 08/21/2016 07:12 AM, Shachar Shemesh wrote:
>> During static analysis, keep both the "most expanded" and the "least
>> expanded" type of the expression parsed so far. "Least expanded" is the
>> largest type actually used in the expression.
>
> What's "most expanded"?
As expanded as we plan on making it. In our current semantics, "int" or "uint".

>
>> Upon use of the value, resolve which type to actually use for it. If the
>> use type requests a type between least and most, use that type for
>> evaluating the entire expression. If the use requests a type outside
>> that range, use the one closest (and, if the use is below the range,
>> complain about narrowing conversion).
>
> So when only ubytes are involved, all calculations would be done on
> ubytes, no promotions, right? There are cases where that would give
> different results than doing promotions.
>
> Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are
> promoted to a larger type, you get 255 as the result. If they are not,
> you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives
> you 127.

You are right. This is a hole in this suggestion. Let me think if it is plugable.

Shachar

On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
> I'll give some highlights, but those are, mostly, things that I've already listed in this forum and in my lightening talk.
>
> - No RAII support, despite the fact everybody here seems to think that D supports RAII.
> Shachar

There IS RAII in D.
I'm using it in DlangUI extensively for managing resources.

On 22/08/16 09:31, Vadim Lopatin wrote:
> On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
>> I'll give some highlights, but those are, mostly, things that I've
>> already listed in this forum and in my lightening talk.
>>
>> - No RAII support, despite the fact everybody here seems to think that
>> D supports RAII.
>> Shachar
>
> There IS RAII in D.
> I'm using it in DlangUI extensively for managing resources.
>
>

Then, depending on your precise use, you might have leaks.

Shachar

On Sunday, 21 August 2016 at 23:07:43 UTC, Solomon E wrote:
>
> The D spec is full of errors, literally, or teasers sometimes.
....
> Erroneous code should be omitted from a spec, or at least clearly marked such as by a red background.
>

I'd like to respond critically to my own silly comment.

It's a great achievement that D has so many features, more versatility than C++, and yet the same few pages can serve as both the language specification and as the language reference for experienced D programmers, and also as an introduction to D features for programmers new to D, and include sufficient examples of what should cause errors as well as what should be valid code. It helps make the language lighter to pick up and better maintained than if it had separate long books of official information for each of those 5 purposes.

So the complaint that errors should have a "red background" is classic bikeshedding about what color to paint the bikeshed. Most people don't have any difficulty seeing "// error" at or near the end of a line as a clear marker that the whole line is an error before they start reading the line as if it might be valid, shifting their intuition of what the text is trying to say, then have the ending surprise them. Most people don't turn around and then think "// ok" is a surprise ending either. Most people don't have any difficulty scanning for sets of valid formulas or sentences to use, or scanning for sets of errors or mistakes to avoid, when incorrect and correct lines are interspersed randomly in a reference or textbook.

Most programmers can handle languages that reverse the order of "if" statements or the order of declaration and use just as well. So putting the indicators of whether a line is an error or correct at the end of a line is an arbitrary, harmless choice.

If a significant number of people did have any problem with that, it would have been cleaned up already. So obviously it isn't a problem and it's just a ridiculous, whiny complaint.

On Monday, 22 August 2016 at 07:05:01 UTC, Shachar Shemesh wrote:
> On 22/08/16 09:31, Vadim Lopatin wrote:
>> On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh
>>> - No RAII support, despite the fact everybody here seems to think that
>>> D supports RAII.
>>> Shachar
>>
>> There IS RAII in D.
>> I'm using it in DlangUI extensively for managing resources.
>>
>
> Then, depending on your precise use, you might have leaks.

To avoid leaks, it's necessary to prevent destructor calling from GC for objects which hold resources - they have to be called manually via destroy() or by some RAII technique.
I'm using Reference Counting.

On Monday, 22 August 2016 at 05:54:17 UTC, Shachar Shemesh wrote:
> On 21/08/16 12:47, ag0aep6g wrote:
>> Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are
>> promoted to a larger type, you get 255 as the result. If they are not,
>> you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives
>> you 127.
>
> You are right. This is a hole in this suggestion. Let me think if it is plugable.


I actually consider that no different than `float a = int(1) / int(2);` and see it as a feature.

But, of course, it does fall under the category of silent breaking change (well, we could warn, but still).

On Sunday, 21 August 2016 at 16:31:41 UTC, Andrei Alexandrescu wrote:
> Consider:
>
> void fun(byte);
> void fun(int);
> fun(b + c);

Does anybody actually do that in the real world? Given the int promotion rule, such an overload is something i'd flag as always bug prone and confusing anyway.

With D's current rules, I am more likely to make just the int version and cast stuff down inside to get user code to compile more easily. My color.d, for example, has this:

        /// Construct a color with the given values. They should be in range 0
<= x <= 255, where 255 is maximum intensity and 0 is minimum intensity.
        nothrow pure @nogc
        this(int red, int green, int blue, int alpha = 255) {
                // workaround dmd bug 10937
                if(__ctfe)
                        this.components[0] = cast(ubyte) red;
                else
                        this.r = cast(ubyte) red;
                this.g = cast(ubyte) green;
                this.b = cast(ubyte) blue;
                this.a = cast(ubyte) alpha;
        }


Just because I got sick of constantly doing the casts on the user side. VRP is brilliant in little cases, but the fact that it doesn't work across statements really hurts it in real world use.

These casts are arguably wrong, defeating the point of the no implicit narrowing rule, but when a rule is so annoying that you hack around it, it has already failed.

On 21/08/16 19:31, Andrei Alexandrescu wrote:
> On 08/20/2016 11:25 AM, Shachar Shemesh wrote:
>> On 20/08/16 00:51, Walter Bright wrote:
>>> On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
>>>> Alas, C insisted on making everything int all the time and D followed
>>>> that :(
>>>
>>
>> Actually, Adam's suggestion on how things should work is precisely how C
>> works (except it trails off at int).
>>
>> a = b + c;
>>
>> if b and c are both a byte, and a is a byte, the result is unpromoted.
>> If a is a short, the result is promoted. I know the mechanism is
>> completely different than what Adam was suggesting, but the end result
>> is precisely the same.
>
> Consider:
>
> void fun(byte);
> void fun(int);
> fun(b + c);
>
> Under the new rule, this code (and much more) would silently change
> behavior. How would that get fixed?
>

Not under my suggested implementation:
> If more than one use is possible (i.e. - overloading), use the largest one applicable.

Shahcar

Take a look on this discussion thread and you know WHY D IS NOT SO POPULAR.

The community discusses technical details and compares D to C++, but there is no clear mission statement, there is no vision statement and no marketing.

Often you merchandise D as a "system programming language", but the market for  "system programming language" is tiny.

D offers so much more, it is the most mature "modern" compiler language with thread-local first principle, which makes it to the best choice for modern server programming projects. It's meta programing facilities gives you a rich base for high level large scale business application projects. Its embedded testing, the module concept ... are great for large scale projects.

I want to use D in an in-house project for a while, but D's marketing is so bad, that it is nearly impossible to convince the management. They feel, that D is instable (much to high version frequency), D is only "a kind of C++" and has no own ecosystem, and there is no (commercial) support.

From my point of view you need to get out of "systems programming language" niche and have to avoid the never ending public detail discussion. Try to position D as THE all purpose programming language for bigger teams. Do better documentation, update Andrei's book so that it is THE BOOK OF D. Maybe you have to split dlang.org into one site facing your customers (as me) and one (more internal) site for discussions and further developement.
Change your release-concept in that way, that you have LTS-releases for your customers (as me) and more experimental releases for your compiler/lib-developer community.

And do marketing, marketing, marketing. Give talks, write (enrty level) articles for popular magazines ..

Regards

Markus

On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
> Take a look on this discussion thread and you know WHY D IS NOT SO POPULAR.
>
> The community discusses technical details and compares D to C++, but there is no clear mission statement, there is no vision statement...
>


Hello,
the url https://dlang.org/overview.html states that "It's a practical language for practical programmers", i think this is the vision statement)))