January 09, 2020
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
>
> [snip]

I think I left off some {}, but the point stands.
January 09, 2020
On Thursday, 9 January 2020 at 13:39:21 UTC, Ola Fosheim Grøstad wrote:
> Thanks for sharing. The language itself looks pretty standard, but it claims to provide two features that could be a selling point for interactive applications:  good C++ interop and hot patching. If they deliver on that, then they could be in a good positition.

Personally the things that I like about it is how clean it looks and how IDE support is taken into account when designing it.
January 09, 2020
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
> On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
>> [...]
>
> I think his point is that do {} while(false) is basically a non-looping do statement. So you can use breaks within it like below (adapting the example from beeflang.org). The only difference I can see is that you can return from Beef's do statement. There's probably a way to do that in D, but I haven't thought a lot about it.
>
> void main() {
>     int result;
>     do {
>         int c = 2;
>         if (c == 0)
>             break;
>         string op = "+";
>         if (op != "+")
>             break;
>         int c2 = 3;
>         if (c2 == 0)
>             break;
>         result = c + c2;
>     } while (false);
>     assert(result == 5);
> }

Yes that. Thanks for clarifying my point.
January 09, 2020
On Thu, Jan 09, 2020 at 04:58:16PM +0000, Basile B. via Digitalmars-d wrote: [...]
> A few good points however
> 
>   1. `??` and `?.` operators. D failed to get those.

Wasn't there a proposal for the "Elvis operator" a while back? Did nobody follow up on it with an actual DIP?  I would support this. It's a pretty useful thing to have to not have to continually check for null-ness in a long chain of dots. A library solution is *possible* but ugly and has corner cases that are not easily handled.


>   2. sane `switch` with implicit `break` and explicit `fallthrough`.

Yeah, I agree `fallthrough` is a much better construct that implicit fallthrough with mandatory repetitive `break`s. I doubt this is possible to change in D at this point, though.  Unless people get onboard with D3. But so far the official stance appears to be that D3 will never happen.

Also, did you know D's switch statement has allow insane syntax, like Duff's device (and many -- far more horrible -- things)?  I'd love to get rid of that, as it needlessly obfuscates code, and any optimizing compiler worth its salt ought to be able to emit that sort of code automatically without needing the programmer to explicitly write it that way.


T

-- 
Fact is stranger than fiction.
January 09, 2020
I find very interesting the approach used to implement struct interfaces without any boxing. Very clean and nice.

struct Circle : IDrawable
{ void Draw() {}  }

/* Calling the following method with an instance of Circle will first cause boxing to occur at the
 callsite, then Draw will be called via dyanmic dispatch (method table) */
public static void DrawDynamic(IDrawable val)
{
    val.Draw();
}

/* Calling the following method with an instance of Circle will create a specialized instance of
the DrawGeneric method which accepts a Circle argument and statically calls the Circle.Draw
 method, which is faster */
public static void DrawGeneric<T>(T val) where T : IDrawable
{
    val.Draw();
}


January 09, 2020
On Thursday, 9 January 2020 at 18:01:10 UTC, JN wrote:
> Personally the things that I like about it is how clean it looks and how IDE support is taken into account when designing it.

Designing with IDE support in mind from the start is the right approach today, absolutely right. Could give them a faster pick up.

The syntax does not win me over, e.g. using "[attribute]" for disabling bounds checking is going to be confusing:

«int val = arr[[Unchecked]i];»

But ultimately its success will depend on delivering solutions that other languages don't provide.

If hot patching works out ok then they could create their own Flutter and given the C# likeness that could be more attractive than Dart, and appeal to a wider audience (could work for both portable mobile Games and Apps, and that would be... significant).

January 09, 2020
On Thursday, 9 January 2020 at 18:51:18 UTC, H. S. Teoh wrote:
> On Thu, Jan 09, 2020 at 04:58:16PM +0000, Basile B. via Digitalmars-d wrote: [...]
>> A few good points however
>> 
>>   1. `??` and `?.` operators. D failed to get those.
>
> Wasn't there a proposal for the "Elvis operator" a while back? Did nobody follow up on it with an actual DIP?  I would support this. It's a pretty useful thing to have to not have to continually check for null-ness in a long chain of dots. A library solution is *possible* but ugly and has corner cases that are not easily handled.

Yes there was an attempt by Razvan7 [1] and following a big discussion on the NG.
The attempt did not succeed because the implementation was, according to Walter, naive in the sense that there were cases where I don't remember what was doubly evaluated, leading to possible side-effects.

The attempt was for the Elvis so "?:" and not "??" (which makes less sense in D because of implicit bool eval of class instance, array, etc.).

[1] https://github.com/dlang/dmd/pull/7242
January 10, 2020
On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
> On Thursday, 9 January 2020 at 16:58:16 UTC, Basile B. wrote:
>>   5. `repeat {} while ()` and `do {}` lacks of orthogonality. `do {} while (false);` could
>>      have been used instead, saving `repeat`. This new statement a very few value added
>>      but I understand that it's tempting to invent small things like that when creating a
>>      language.
>
> do {} has a separate meaning in beef. These blocks are not looping, but using break; is valid in them to skip to their end. While this is certainly creative, I don't know if it all that useful. But it burns the "do" keyword in the grammar and something else is required to start a do/while block.

What? They put that asinine "do {break; } while(0)" non-looping loop C idiom in the language as a 1st order construct?
That language is therefore officially deadbeef for me.

I hate that construct with a passion (I had to work on too much code using that). It is an obfuscated goto for people who want to use gotos but are not man enough to actually use goto. It is worse that a real goto, as with a real goto you have a label at the destination.
January 10, 2020
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
> On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
>> [snip]
>>
>> do {} has a separate meaning in beef. These blocks are not looping, but using break; is valid in them to skip to their end. While this is certainly creative, I don't know if it all that useful. But it burns the "do" keyword in the grammar and something else is required to start a do/while block.
>
> I think his point is that do {} while(false) is basically a non-looping do statement. So you can use breaks within it like below (adapting the example from beeflang.org). The only difference I can see is that you can return from Beef's do statement. There's probably a way to do that in D, but I haven't thought a lot about it.
>
> void main() {
>     int result;
>     do {
>         int c = 2;
>         if (c == 0)
>             break;
>         string op = "+";
>         if (op != "+")
>             break;
>         int c2 = 3;
>         if (c2 == 0)
>             break;
>         result = c + c2;
>     } while (false);
>     assert(result == 5);
> }

Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify.

void main() {
    int result;
    int c = 2;
    if (c == 0)
      goto skip;
    string op = "+";
    if (op != "+")
      goto skip;
    int c2 = 3;
    if (c2 == 0)
      goto skip;
    result = c + c2;
skip:
    assert(result == 5);
}


Never use the do {} while(false) construct, it's stupid. Burn it with fire.

PS: yes, I'm passionate about that construct; it poisoned our code base because of a colleague who used it all the time. It is a real pain to get rid of it (of course they were not used in a 10 line example, but in 300/400 lines nested behemoths).
January 10, 2020
On Friday, 10 January 2020 at 09:00:53 UTC, Patrick Schluter wrote:
> On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
>> void main() {
>>     int result;
>>     do {
>>         int c = 2;
>>         if (c == 0)
>>             break;
>>         string op = "+";
>>         if (op != "+")
>>             break;
>>         int c2 = 3;
>>         if (c2 == 0)
>>             break;
>>         result = c + c2;
>>     } while (false);
>>     assert(result == 5);
>> }
>
> Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify.
>
> void main() {
>     int result;
>     int c = 2;
>     if (c == 0)
>       goto skip;
>     string op = "+";
>     if (op != "+")
>       goto skip;
>     int c2 = 3;
>     if (c2 == 0)
>       goto skip;
>     result = c + c2;
> skip:
>     assert(result == 5);
> }
>

or don't do too many things at-once:

void main() {
  auto result() {
    int c = 2;
    if (c == 0)
      return c;
    string op = "+";
    if (op != "+")
      return c;
    int c2 = 3;
    if (c2 == 0)
      return c;
    return c + c2;
  }
  assert(result == 5);
}