June 11, 2021

On Friday, 11 June 2021 at 13:36:27 UTC, Ola Fosheim Grøstad wrote:

>

On Friday, 11 June 2021 at 13:10:23 1. First insulate independent parts. So, insulate the backend from the front end, by putting a layer between (most likely a high level IR).

D team members should have a listen to your advice.
Your suggestion are always very good.

June 11, 2021

i disagree, polluting code with compiler specific sheningans is the root of all evil

don't bloat code that is already hard to read for features people want to test

it's meant to be transitive, something temporary, not something that needs to live on people's code

let's just stop with the @ bloat

other aspect of D needs love, it certainly not the -preview thing, that is a pure waste of time

June 11, 2021
> I would find it much more reassuring if a comprehensive solution was developed as a completely separate compiler branch. Basically have a stable branch (as is), and then a future branch that is considered unstable until all the corner cases have been ironed out.

Separating `stable` release vs `development` experiment branch is something that have been discussed on this forum for so many times, (last time I remember is `safe` vs `system` by default discussion).

I think what we need is action! I.e take it into action. Seriously.
June 11, 2021
On Friday, 11 June 2021 at 21:59:21 UTC, mw wrote:
>> I would find it much more reassuring if a comprehensive

We first need orgnazition,random action is of no use.
D need organization,dispatch tasks,Repeate 3 times.
June 12, 2021

On Friday, 11 June 2021 at 07:36:47 UTC, Sönke Ludwig wrote:

>
@semantic("dip1000") @semantic("default-to-safe")
@disableSemantic("dip999")
module foo;

+1, but a possible problem with this is scoping. How does a variable interact with another being rule differently.

1 2 3
Next ›   Last »