www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D1.5 anyone?

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I've often see people clamoring for D3 to set things right. But 
me I want D1.5, I want to return to that simple and beautiful 
language that was designed by Walter Bright.

Interestingly enough if we simple disable semantic check for 
transitive qualifiers relegating them to pure annotations to be 
used by lint tool we can get to basically where D1 was in 2007. 
Why picking on transitive qualifiers, I explain in a new blog 
post here:
https://olshansky.me/posts/d-biggest-mistake/

Thoughts? I'm going to do D1.5 for myself but wanted to know if 
anyone feels the same.

---
Dmitry Olshansky
Apr 11 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:

 Interestingly enough if we simple disable semantic check for 
 transitive qualifiers relegating them to pure annotations to be


I've actually thought about making a `-betterD` switch that 
disables most the annotations, turning them to no-ops.

But your first sentence:


 Make no mistake - thread-local by default is great!


Gonna go ahead and disagree with that, the thread local by 
default I think is a mistake now. It causes as many problems as 
it solves.

I'd suggest just making all the global variables need explicit 
designation of shared or thread local.


 Unlike transitive const, shallow const (~ Java’s final)


You might recall that D used to have that back in the day!
Apr 11 2023
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Tuesday, 11 April 2023 at 13:08:33 UTC, Adam D Ruppe wrote:

 On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky 
 wrote:

 Interestingly enough if we simple disable semantic check for 
 transitive qualifiers relegating them to pure annotations to be


 I've actually thought about making a `-betterD` switch that 
 disables most the annotations, turning them to no-ops.

 But your first sentence:


 Make no mistake - thread-local by default is great!


 Gonna go ahead and disagree with that, the thread local by 
 default I think is a mistake now. It causes as many problems as 
 it solves.


If needed we may introduce __threadlocal, what should be the 
default is a question of compatibility with current D2.

 I'd suggest just making all the global variables need explicit 
 designation of shared or thread local.


 Unlike transitive const, shallow const (~ Java’s final)


 You might recall that D used to have that back in the day!
Apr 11 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 11 April 2023 at 13:32:53 UTC, Dmitry Olshansky wrote:

 On Tuesday, 11 April 2023 at 13:08:33 UTC, Adam D Ruppe wrote:

 On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky 
 wrote:

 Interestingly enough if we simple disable semantic check for 
 transitive qualifiers relegating them to pure annotations to 
 be


 I've actually thought about making a `-betterD` switch that 
 disables most the annotations, turning them to no-ops.

 But your first sentence:


 Make no mistake - thread-local by default is great!


 Gonna go ahead and disagree with that, the thread local by 
 default I think is a mistake now. It causes as many problems 
 as it solves.


 If needed we may introduce __threadlocal, what should be the 
 default is a question of compatibility with current D2.



With choose, for a new keyword, something very ugly?

I don't want to write ugly code, let that to C++ and Rust

tls by default is a huge mistake, i support adam's suggestion

Please, make good and simple syntax, anything that starts with __ 
is ugly

The only reason i personally use ``const`` is to be able to pass 
things either by reference or to avoid GC allocation

     void pass(const scope int[] a)
     pass([1,2,3])

I see code in phobos that abuse everything, then abuse workaround


     return ()  trusted { return getAddressInfoImpl(node, service, 
&hints); }();

https://github.com/dlang/phobos/blob/01a12f919e624b3f7b73171ae03d4d0a91a0b87b/std/socket.d#L916-L943

OOP, bloatware, syntax-uglifier people designing stuff should be 
put to jail

If D3 or D1.5 every happen, hopefully that kind of stuff 
disappears, 0 compatibility with that code
Apr 14 2023
next sibling parent IGotD- <nise nise.com> writes:
On Friday, 14 April 2023 at 18:33:50 UTC, ryuukk_ wrote:

 The only reason i personally use ``const`` is to be able to 
 pass things either by reference or to avoid GC allocation


I think that const as function parameter designation is a mistake 
in computer science history. Swift has done this more right. ALL 
parameters are immutable, if you write to a parameter then the 
compiler will create a copy of it on the callee stack frame (not 
caller stack frame as often today, but it is also a definition 
who it belongs to).

The copy parameter by default is one of these mysteries to me 
that is adopted by many languages.

I actually think that writes to parameters (that are not 
references) should be disallowed. If you want to write to it you 
should make a copy of it by assignment (ie. manually copy it).
Apr 14 2023
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 14 April 2023 at 18:33:50 UTC, ryuukk_ wrote:

 On Tuesday, 11 April 2023 at 13:32:53 UTC, Dmitry Olshansky 
 wrote:

 [...]



 With choose, for a new keyword, something very ugly?

 [...]


One word  - backward compatibility. Keywords with __ are reserved 
by the compiler.

 [...]


Maybe.


 [...]


It will be an experiment, a backwards compatible one.

 disappears, 0 compatibility with that code
Apr 15 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 15 April 2023 at 10:29:10 UTC, Dmitry Olshansky 
wrote:

 On Friday, 14 April 2023 at 18:33:50 UTC, ryuukk_ wrote:

 On Tuesday, 11 April 2023 at 13:32:53 UTC, Dmitry Olshansky 
 wrote:

 [...]



 With choose, for a new keyword, something very ugly?

 [...]


 One word  - backward compatibility. Keywords with __ are 
 reserved by the compiler.


If it's reserved by the compiler, it shouldn't be available for 
me to type, nor should it be providing a workaround to a poor 
design (tls)

What the user supposed to do?




 [...]


 Maybe.


 [...]


 It will be an experiment, a backwards compatible one.

 disappears, 0 compatibility with that code




Why backward when we can move forward? maintaining bad design is 
not desirable, at least to me, i'd rather move forward


This is a disconnect in D, the expectation that everyone is a 
compiler dev, and everyone should subscribe to maintaining the 
existence of poor design

As a result i have to type __gshared all over my code base, wich 
i hate so much that i'm willing to work D to rename that to 
notls, or  notls, unfortunatly i am not a compiler dev, so i have 
to cope with it, wich frankly is not something i want to deal 
with forever, at some point i'll move on and embrace a different 
language, unfortunatly, there is nothing on the market that's 
good enough to justify me porting over my code, again..
Apr 17 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 18/04/2023 3:54 AM, ryuukk_ wrote:

 As a result i have to type __gshared all over my code base, wich i hate 
 so much that i'm willing to work D to rename that to notls, or  notls, 
 unfortunatly i am not a compiler dev, so i have to cope with it, wich 
 frankly is not something i want to deal with forever, at some point i'll 
 move on and embrace a different language, unfortunatly, there is nothing 
 on the market that's good enough to justify me porting over my code, 
 again..


We need that for fibers/coroutines to be safe so at some point it needs 
to be added anyway.

However TLS in -betterC should be fixed in ~master.
Apr 17 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 17 April 2023 at 15:57:55 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 18/04/2023 3:54 AM, ryuukk_ wrote:

 As a result i have to type __gshared all over my code base, 
 wich i hate so much that i'm willing to work D to rename that 
 to notls, or  notls, unfortunatly i am not a compiler dev, so 
 i have to cope with it, wich frankly is not something i want 
 to deal with forever, at some point i'll move on and embrace a 
 different language, unfortunatly, there is nothing on the 
 market that's good enough to justify me porting over my code, 
 again..


 We need that for fibers/coroutines to be safe so at some point 
 it needs to be added anyway.

 However TLS in -betterC should be fixed in ~master.


That's great to hear, finally some progress, however, the other 
program is still there, i have to type __gshared when i don't 
want tls to be the default, wich i don't like
Apr 17 2023
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 17 April 2023 at 15:54:40 UTC, ryuukk_ wrote:

 On Saturday, 15 April 2023 at 10:29:10 UTC, Dmitry Olshansky 
 wrote:

 [...]


 If it's reserved by the compiler, it shouldn't be available for 
 me to type, nor should it be providing a workaround to a poor 
 design (tls)

 [...]


Nope, compatibilty is what makes the world work, we had D1->D2, 
so no thanks.

 [...]
Apr 17 2023
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 4/11/23 14:21, Dmitry Olshansky wrote:

 I've often see people clamoring for D3 to set things right. But me I 
 want D1.5, I want to return to that simple and beautiful language that 
 was designed by Walter Bright.
 
 Interestingly enough if we simple disable semantic check for transitive 
 qualifiers relegating them to pure annotations to be used by lint tool 
 we can get to basically where D1 was in 2007. Why picking on transitive 
 qualifiers, I explain in a new blog post here:
 https://olshansky.me/posts/d-biggest-mistake/
 
 Thoughts? I'm going to do D1.5 for myself but wanted to know if anyone 
 feels the same.
 ...


Some of mine:

- I am in favor of exploring this idea. It's certainly better than what 
we have now.

- 'val'/'var' is terrible terminology for talking about mutability.

- The most salient things about functional programming are that 
variables hold values and functions are deterministic. Lack of 
mutability is not really fundamental. Ownership and move semantics can 
give you mutable value types even in a purely functional programming 
language and those are pretty useful as well, as they can be passed 
between threads almost as easily as immutable data. (It's a special case 
of `isolated`.) This is something to keep in mind as it's not really 
available in Scala.

- I think it is right that mutability/ownership is naturally a storage 
class and not really a type qualifier. You don't change what you have, 
just how you access it. (It's also what we have been doing for "const" 
in Silq.) However, you may still want to parameterize a type by a 
storage class.

- A story for how this affects built-in types is still somewhat absent. 
I quite like the ergonomics of types like `immutable(char)[]` and 
`immutable(ubyte)[]`, I would be sad to see them go. However, also here, 
it's not naturally the element type that is modified by the qualifier, 
it's more naturally the array type that is modified, here in a somewhat 
hacky way based on the qualifiers on the element type.

- Immutability by interface is already the best way to do immutability 
in a single-threaded environment, for multithreading probably an 
`immutable` storage class can be helpful.

- I feel like the story for multithreading in your post is currently 
almost the least fleshed-out part of it, but maybe something can be 
designed here. Manu has been in favor of allowing things to implicitly 
cast to `shared`. With transitive qualifiers this just cannot be safe, 
but with what you propose I think we can make his vision work. There 
would still need to be some transitive-ish enforcement. Basically, by 
default you should not be able to access an un`shared` field of a shared 
variable. With shared as a storage class, you can actually make 
variables shared temporarily in a safe manner, exactly in the way that 
Manu imagined for his safe parallel foreach.
Apr 11 2023
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 4/11/23 18:43, Timon Gehr wrote:

 
 - Immutability by interface is already the best way to do immutability 
 in a single-threaded environment, for multithreading probably an 
 `immutable` storage class can be helpful.


I guess initialization of such data structures will be a bit annoying as 
`immutable` as a non-transitive storage class kills pure factory functions.
Apr 11 2023
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Tuesday, 11 April 2023 at 16:47:05 UTC, Timon Gehr wrote:

 On 4/11/23 18:43, Timon Gehr wrote:

 
 - Immutability by interface is already the best way to do 
 immutability in a single-threaded environment, for 
 multithreading probably an `immutable` storage class can be 
 helpful.


 I guess initialization of such data structures will be a bit 
 annoying as `immutable` as a non-transitive storage class kills 
 pure factory functions.


That much is true. What I have in mind is to reconcile pure 
functions and CTFE-ability. It would seem that any pure function 
could CTFE-ed.
Apr 11 2023
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 4/11/23 18:43, Timon Gehr wrote:

 
 - I feel like the story for multithreading in your post is currently 
 almost the least fleshed-out part of it, but maybe something can be 
 designed here. Manu has been in favor of allowing things to implicitly 
 cast to `shared`. With transitive qualifiers this just cannot be safe, 
 but with what you propose I think we can make his vision work. There 
 would still need to be some transitive-ish enforcement. Basically, by 
 default you should not be able to access an un`shared` field of a shared 
 variable. With shared as a storage class, you can actually make 
 variables shared temporarily in a safe manner, exactly in the way that 
 Manu imagined for his safe parallel foreach.


It's not so clear how this would interact with `immutable`.

I guess another complication absent from Scala is that D has structs.
Apr 11 2023
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Tuesday, 11 April 2023 at 16:43:08 UTC, Timon Gehr wrote:

 On 4/11/23 14:21, Dmitry Olshansky wrote:

 [...]


 - A story for how this affects built-in types is still somewhat 
 absent. I quite like the ergonomics of types like 
 `immutable(char)[]` and `immutable(ubyte)[]`, I would be sad to 
 see them go. However, also here, it's not naturally the element 
 type that is modified by the qualifier, it's more naturally the 
 array type that is modified, here in a somewhat hacky way based 
 on the qualifiers on the element type.


As a transitory period we could keep transitive qualifier 
machinery in place under a flag, then run it as lint and if 
string stays immutable(char)[] you’d get an error trying to 
modify its elements. Just a thought.


 - I feel like the story for multithreading in your post is 
 currently almost the least fleshed-out part of it, but maybe 
 something can be designed here. Manu has been in favor of 
 allowing things to implicitly cast to `shared`. With transitive 
 qualifiers this just cannot be safe, but with what you propose 
 I think we can make his vision work. There would still need to 
 be some transitive-ish enforcement. Basically, by default you 
 should not be able to access an un`shared` field of a shared 
 variable. With shared as a storage class, you can actually make 
 variables shared temporarily in a safe manner, exactly in the 
 way that Manu imagined for his safe parallel foreach.


Need to read his proposal.

—
Dmitry Olshansky
Apr 11 2023
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:

 I've often see people clamoring for D3 to set things right. But 
 me I want D1.5, I want to return to that simple and beautiful 
 language that was designed by Walter Bright.

 Interestingly enough if we simple disable semantic check for 
 transitive qualifiers relegating them to pure annotations to be 
 used by lint tool we can get to basically where D1 was in 2007. 
 Why picking on transitive qualifiers, I explain in a new blog 
 post here:
 https://olshansky.me/posts/d-biggest-mistake/

 Thoughts? I'm going to do D1.5 for myself but wanted to know if 
 anyone feels the same.

 ---
 Dmitry Olshansky


My solution to D const was pretty simple: Never use it :D
It makes things painfully to work with most of the time and I'm 
yet to see any real advantage over using it.
My main language after D is typescript and well, for something 
become const is really hard in it, so I find it pretty nice to 
doesn't use. Specially in the game development thing where 
mutability exists.


`pure` breaks logging in your function for debugging, `const` you 
need to specify it everywhere or else your thing won't compile. 
This is a great friction I get which I took the decision to just 
drop those.
Apr 11 2023
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Tuesday, 11 April 2023 at 17:30:34 UTC, Hipreme wrote:

 On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky 
 wrote:

 [...]


 My solution to D const was pretty simple: Never use it :D


That’s what I do in my projects except for strings. In standard 
library however I had to reset to all sorts ugly hack to make 
immutable regex work.


 It makes things painfully to work with most of the time and I'm 
 yet to see any real advantage over using it.
 My main language after D is typescript and well, for something 
 become const is really hard in it, so I find it pretty nice to 
 doesn't use. Specially in the game development thing where 
 mutability exists.


Agreed.


 `pure` breaks logging in your function for debugging,


Oh the joy of pure functions.

—
Dmitry Olshansky
Apr 11 2023
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 11 April 2023 at 17:30:34 UTC, Hipreme wrote:

 `pure` breaks logging in your function for debugging


You can use a debug statement for that, which looks like `debug 
writeln("log");`. Or, what I do, create a 'debug print' function 
that looks like something this:
```D
void dprint(T...)(auto ref T args, int line = __LINE__, string 
file = __FILE__)
{
     debug writeln(file, "(", line, "): ", args);
}
```
Apr 11 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2023 10:30 AM, Hipreme wrote:

 `pure` breaks logging in your function for debugging,


That's why the following works:

pure void foo()
{
     debug printf("inside foo()\n");
}



 `const` you need to 
 specify it everywhere or else your thing won't compile. This is a great
friction 
 I get which I took the decision to just drop those.


True, you can just not use const.
Apr 11 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Consider the following:

     shared int* p;

With transitive shared, that makes p and *p both shared. If I'm understanding 
your post, you propose changing things so p is shared and *p is not shared.

The issue with that is *p loses what thread it belongs to, and will then (to be 
thread safe) have to be synchronized.

I agree it is likely easier to write programs this way, but I suspect it will
be 
a lot harder to write correct programs, and the compiler will be unable to help 
with that.

I have thought about head const (aka final) many times, but didn't come to any 
conclusions.
Apr 11 2023
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 12 April 2023 at 05:10:36 UTC, Walter Bright wrote:

 Consider the following:

     shared int* p;

 With transitive shared, that makes p and *p both shared. If I'm 
 understanding your post, you propose changing things so p is 
 shared and *p is not shared.

 The issue with that is *p loses what thread it belongs to, and 
 will then (to be thread safe) have to be synchronized.

 I agree it is likely easier to write programs this way, but I 
 suspect it will be a lot harder to write correct programs, and 
 the compiler will be unable to help with that.


Humanity has been writing concurrent programs even without 
explicit shallow shared for decades now. Together with explicit 
head-shared we are strictly better than status quo.



 I have thought about head const (aka final) many times, but 
 didn't come to any conclusions.
Apr 11 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2023 10:36 PM, Dmitry Olshansky wrote:

 Humanity has been writing concurrent programs even without explicit shallow 
 shared for decades now.


Of course you're right. And suffered endless weird and hard to debug problems.



 Together with explicit head-shared we are strictly 
 better than status quo.


Are we in terms of safety and correctness?
Apr 11 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 12/04/2023 6:42 PM, Walter Bright wrote:

 Together with explicit head-shared we are strictly better than status 
 quo.


 
 Are we in terms of safety and correctness?


I remain sincerely unconvinced.

Shared is the exact opposite of what is needed.

Unless proven otherwise, all memory is owned by the process not the 
thread and therefore is the default.

The only way I've been able to use it successfully is to treat it as if 
it was `atomic`. Only without any of the QoL stuff that `atomic` could 
bring.
Apr 12 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2023 12:11 AM, Richard (Rikki) Andrew Cattermole wrote:

 Unless proven otherwise, all memory is owned by the process not the thread and 
 therefore is the default.


Let's see if I understand:

     int abc(int* p);

     int sum(int[] a)
     {
         int sum = 0;
         abc(&sum);
         for (int i = 0; i < a.length; ++i)
             sum += a[i];
         return sum;
     }

Your position is that `i` and `sum` should be shared variables? What if 
`abc(&sum)` passes `&sum` to a concurrent thread?
Apr 12 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 12/04/2023 7:27 PM, Walter Bright wrote:

 On 4/12/2023 12:11 AM, Richard (Rikki) Andrew Cattermole wrote:

 Unless proven otherwise, all memory is owned by the process not the 
 thread and therefore is the default.


 
 Let's see if I understand:
 
      int abc(int* p);
 
      int sum(int[] a)
      {
          int sum = 0;
          abc(&sum);
          for (int i = 0; i < a.length; ++i)
              sum += a[i];
          return sum;
      }
 
 Your position is that `i` and `sum` should be shared variables? What if 
 `abc(&sum)` passes `&sum` to a concurrent thread?


No, you have that backwards.

In both of those cases its owned by the thread. With  safe they would be 
scope, which is a partial implementation of 'owned by thread' checking.

A better example would be `a`. This is an argument, with an unknown 
memory lifetime or ownership, that should be shared implicitly even if 
it was marked scope.
Apr 12 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2023 12:38 AM, Richard (Rikki) Andrew Cattermole wrote:

 On 12/04/2023 7:27 PM, Walter Bright wrote:

 On 4/12/2023 12:11 AM, Richard (Rikki) Andrew Cattermole wrote:

 Unless proven otherwise, all memory is owned by the process not the thread 
 and therefore is the default.


 Let's see if I understand:

      int abc(int* p);

      int sum(int[] a)
      {
          int sum = 0;
          abc(&sum);
          for (int i = 0; i < a.length; ++i)
              sum += a[i];
          return sum;
      }

 Your position is that `i` and `sum` should be shared variables? What if 
 `abc(&sum)` passes `&sum` to a concurrent thread?


 
 No, you have that backwards.
 
 In both of those cases its owned by the thread. With  safe they would be
scope, 
 which is a partial implementation of 'owned by thread' checking.


Then I don't know what you mean by default being shared. And why would  safe 
influence this?



 A better example would be `a`. This is an argument, with an unknown memory 
 lifetime or ownership, that should be shared implicitly even if it was marked 
 scope.


Such implicit sharing means C semantics, where the compiler assumes that none
of 
it is shared, and there are no protections and it's all up to the programmer to 
put in synchronization code where necessary.

You can actually do that now in D, just leave off the 'shared' annotations.
Apr 12 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 13/04/2023 5:06 AM, Walter Bright wrote:

 In both of those cases its owned by the thread. With  safe they would 
 be scope, which is a partial implementation of 'owned by thread' 
 checking.


 
 Then I don't know what you mean by default being shared. And why would 
  safe influence this?


Default being shared I mean in terms of equivalence of behavior and 
purpose of shared itself.

 safe influences it because of DIP1000 with scope, which gives memory a 
lifetime that is tracked across a thread.


 A better example would be `a`. This is an argument, with an unknown 
 memory lifetime or ownership, that should be shared implicitly even if 
 it was marked scope.


 
 Such implicit sharing means C semantics, where the compiler assumes that 
 none of it is shared, and there are no protections and it's all up to 
 the programmer to put in synchronization code where necessary.
 
 You can actually do that now in D, just leave off the 'shared' annotations.


Exactly. You can leave it off and you have the same guarantees you have 
with shared being on (ignoring nosharedaccess as that is essentially 
turning it into atomic without any of the QoL stuff).

We can talk about this some other time perhaps at a BeerConf if you're 
on when I can talk. I do have a lot of things to talk about that are a 
bit exciting (and plenty of bugs like unresolved RTInfoImpl's with dmd)!
Apr 12 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2023 10:50 PM, Richard (Rikki) Andrew Cattermole wrote:

 We can talk about this some other time perhaps at a BeerConf if you're on when
I 
 can talk. I do have a lot of things to talk about that are a bit exciting (and 
 plenty of bugs like unresolved RTInfoImpl's with dmd)!


Ok. But I suggest writing down your thoughts, complete with examples and such.
I 
have a hard time picturing just what your proposal is.
Apr 13 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/04/2023 7:38 AM, Walter Bright wrote:

 On 4/12/2023 10:50 PM, Richard (Rikki) Andrew Cattermole wrote:

 We can talk about this some other time perhaps at a BeerConf if you're 
 on when I can talk. I do have a lot of things to talk about that are a 
 bit exciting (and plenty of bugs like unresolved RTInfoImpl's with dmd)!


 
 Ok. But I suggest writing down your thoughts, complete with examples and 
 such. I have a hard time picturing just what your proposal is.


- Remove ``shared(T)``
- Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode 
(like -preview=nosharedaccess introduces, or having to cast away shared).

Basically everything I have to say is rather academic in nature, not 
very practical, there are arguments both for and against everything 
practical I can suggest.

 From my reading of research papers regarding coroutines, pretty much 
all the concurrency primitives that we know of today for PL design was 
already invented by 1976 with an implementation; this is very much an 
open problem still.

I really enjoyed this particular passage from one paper as it shows just 
how little things have changed in 50 years:


 However, this paper also ignores many serious problems. The most 


serious is that it fails to suggest any proof method to assist in the 
development and verification of correct programs.
Apr 13 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2023 5:59 PM, Richard (Rikki) Andrew Cattermole wrote:

 - Remove ``shared(T)``
 - Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode (like 
 -preview=nosharedaccess introduces, or having to cast away shared).


That looks like the way C11 does it.
Apr 17 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 18/04/2023 2:12 PM, Walter Bright wrote:

 On 4/13/2023 5:59 PM, Richard (Rikki) Andrew Cattermole wrote:

 - Remove ``shared(T)``
 - Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode 
 (like -preview=nosharedaccess introduces, or having to cast away shared).


 
 That looks like the way C11 does it.


Yeah that covers atomic variables, but doesn't cover any sort of 
concurrency safety. In a way its very similar to our simd stuff in the 
language. Although in saying that the simd stuff should be on the 
deprecation path, its not needed and is a distraction to getting your 
code performant.

Modern backends are just too good, you can 100% do everything you want 
with just static arrays and almost certainly do it without writing a 
single intrinsic. gdc/ldc can do things that clang cannot, they are amazing!

Also array ops <3
Apr 17 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
 Templates without extreme precautions and Unqual!T all around will get 


instantiated up to 3x(!) times.

I'm not sure why `Unqual!T` exists. `cast()T` will remove all the head 
qualifiers, no templates involved.
Apr 12 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2023 12:05 AM, Walter Bright wrote:

  > Templates without extreme precautions and Unqual!T all around will get 
 instantiated up to 3x(!) times.
 
 I'm not sure why `Unqual!T` exists. `cast()T` will remove all the head 
 qualifiers, no templates involved.


Oops. That is, cast()E will remove all the qualifiers from the type of E. So 
Unqual!T needs to exist. My mistake.
Apr 12 2023
parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 12 April 2023 at 07:33:00 UTC, Walter Bright wrote:

 On 4/12/2023 12:05 AM, Walter Bright wrote:

  > Templates without extreme precautions and Unqual!T all 
 around will get instantiated up to 3x(!) times.
 
 I'm not sure why `Unqual!T` exists. `cast()T` will remove all 
 the head qualifiers, no templates involved.


 Oops. That is, cast()E will remove all the qualifiers from the 
 type of E. So Unqual!T needs to exist. My mistake.


Example? My quick-and-dirty tests say that `cast() x` removes 
only the head qualifiers. Well if you have a struct with 
default-mutable members, `immutable` will be removed from the 
fields too (I think) but I don't think `Unqual!X` is different in 
that regard.

I believe the primary difference is that `cast() x` works on the 
value, while `Unqual!X` works on the type.
Apr 19 2023
prev sibling next sibling parent Guillaume Piolat <first.last spam.org> writes:
On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:

 Thoughts?



One of the point of D type system is also to bring us native 
programmers to memory-safety (and purity), so I think the 
aspirational part of it shouldn't be discounted.

Like how D brought us to living with the GC.

While I'm not a fan of pure, shared, and constness, I can live 
with them and eventually change my mind. Over the years I'm using 
more  safe and pure. pure removal was discussed in last meeting 
and apparently it's still worth having it. Now if we had a 
` trustedPure` or equivalent, that would be cool.
Apr 13 2023
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:

 https://olshansky.me/posts/d-biggest-mistake/


So you were bitten by abuse of qualifiers and now want a language 
that doesn't let you abuse qualifiers? I write D2 code without 
abusing qualifiers and I'm perfectly fine.
Apr 14 2023
prev sibling parent WollyTheWombat <WollyTheWombat gmail.com> writes:
On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:

 Thoughts? I'm going to do D1.5 for myself but wanted to know if 
 anyone feels the same.


Whether forwards or backwards, someone should first write a 
paper/article/whatever, exploring 'the darker side of D'.

We need a 'Markku Sakkinen' like paper (he wrote one back in the 
early 90s called "The darker side of C++ revisited".

I expect some people over at Micrsoft had a good read of that 


My guess is, his view has still not changed:

"..taking the weakly typed and weakly structured language C as a 
base has become an irremediable handicap."
Apr 14 2023