October 11, 2021
On Monday, 11 October 2021 at 21:32:52 UTC, 12345swordy wrote:
> [snip]
> Before you ask, No, using string mixin or templates for implementing interfaces  is NOT considered to be a default interface implementation.
> See here: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/default-interface-methods.md
>
>
> - Alex

Interfaces can have final methods, you just can't overwrite them.
October 11, 2021
>
  • Worst features implemented in a non-toy language
  • Embedding js in an html document.

  • adding objects to an existing language

>
  • Worst features (in your opinion) in D
  • nontrivial namespace collisions when importing std

  • int promotion

  • verbose enums

  • contracts and all the cute ideas expanding a template header to affect the matching

  • sword of damocles of safe by default or who knows what koolaid being enabled one day

>
  • Features you'd like to see in D
  • base types having fake opoverloads ( 2.opCmp(3) == 1)

  • universal function call syntax being universal (let me define a function in the same scope that I ufcs it)

  • a nice overload for _____TrAiTs(compiles,mixin("foo.bar"))

October 11, 2021

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features (in your opinion) in D

Attribute soup

  1. inconsistent - some with leading '@' & some without
    all attributes should start with @. This will help to reduce number of key/reserved words

  2. need re-declare attributes for aggregated types (struct/class) even if it is already declared on module level

  3. All attributes should be non-negative word and introduce negation
    Ex: @gc:
    @nogc become @!gc

Simple example
module x;

@!gc @!throw:

void funcionDoNotThrow() {}

// Reverse the above module attribute setting
void functionThrow() @throw {}

October 11, 2021
On Monday, 11 October 2021 at 21:40:08 UTC, jmh530 wrote:
> On Monday, 11 October 2021 at 21:32:52 UTC, 12345swordy wrote:
>> [snip]
>> Before you ask, No, using string mixin or templates for implementing interfaces  is NOT considered to be a default interface implementation.
>> See here: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/default-interface-methods.md
>>
>>
>> - Alex
>
> Interfaces can have final methods, you just can't overwrite them.

Did you not read the file that I linked?

- Alex
October 11, 2021

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Ideas? Examples?

Thanks!

__traits should've died years ago. Its continued existence shows some level of paralysis.

The decision to build languages as monolithic lumps of specification, then a compiler, also phased in it's design, while simple, I think will be a detriment in the post Moore's law age, as it makes it very irritating to use and understand the full muscle of the optimizer in the right places - and fundamentally limits the potential of the/a language in a now post-heterogenous world: you should he able to compile for a GPU as part of the compiler a la a trait (This is an acceptable use of the keyword, reflection is not).

I think D's worst feature is really a human tendency to avoid language solutions for things. sumtype is a good library, but it should be core language for example. Typecons.tuple is even less marginal.

My dream feature for D is a combination of static analysis, formal verification, and some brand of mutation testing guided by them (When we spoke about it last, Atila, you convinced me but it would take someone more dedicated than I to implement it)

October 11, 2021

On Monday, 11 October 2021 at 21:38:17 UTC, russhy wrote:

>

it just is when you don't need it, you need to be careful with @nogc, and there is no way to globally enforce a @nogc behavior

try a @nogc main() function. Yes this doesn't handle module global and thread constructors, but its global enough.

October 12, 2021

On Monday, 11 October 2021 at 22:01:34 UTC, max haughton wrote:

>

The decision to build languages as monolithic lumps of specification, then a compiler, also phased in it's design, while simple, I think will be a detriment in the post Moore's law age, as it makes it very irritating to use and understand the full muscle of the optimizer in the right places - and fundamentally limits the potential of the/a language in a now post-heterogenous world: you should he able to compile for a GPU as part of the compiler a la a trait (This is an acceptable use of the keyword, reflection is not).

I think a big problem from an exploratory perspective is that that is essentially
impossible in a one-file-at-a-time compilation world and that to explore the space
of possibilities far more people than the D community has.
This afflicts
C, C++, OpenCL, IPSC (1 file at a time, lack of anything other than immediate local context)
CUDA, SYCL, (one file at a time, but lets do it twice! one for the host, one for the device)
OpenMP (where premature outlining for device offloading has caused massive missed optimisation opportunity)

>

I think D's worst feature is really a human tendency to avoid language solutions for things. sumtype is a good library, but it should be core language for example. Typecons.tuple is even less marginal.
__traits should've died years ago. Its continued existence shows some level of paralysis.

in a static slice of time, yes. As a feature to easily add language functionality, without taking up more keywords, with minimal "feature space", its indispensable. It does however show that a program needs an API to the compiler during compilation. Is there a better way to do this? core.reflect and core.codegen seem like good steps.

October 12, 2021

On Monday, 11 October 2021 at 21:41:45 UTC, monkyyy wrote:

>
  • nontrivial namespace collisions when importing std

Are these still around? This compiles now:

unittest {
    import std;

    assert(!std.ascii.isAlpha('5'));
}

unittest {
    import std;
    import std.ascii : isAlpha;

    assert(isAlpha('X'));
    assert(std.uni.isAlpha('X'));
}
October 12, 2021

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features (in your opinion) in D

real, specifically fp80 real. Its slow, its almost always unintentional and phobos tends to use it way more than it should.

October 12, 2021
On Monday, 11 October 2021 at 21:54:05 UTC, 12345swordy wrote:
> [snip]
>>
>> Interfaces can have final methods, you just can't overwrite them.
>
> Did you not read the file that I linked?
>
> - Alex

I skimmed it.