www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is D unpopular, redux.

reply deadalnix <deadalnix gmail.com> writes:
So I was catching up with he humongous thread. What stroke me in 
there is that almost everybody is missing the point, but maybe 
that isn't so surprising, as there is a self selection bias at 
play.

I especially noticed this post: 
https://forum.dlang.org/post/kkmlkebnsbembkispcya forum.dlang.org

Apparently, we are getting named argument soon. I have no opinion 
whether this is good or bad, I haven't even read he proposal. But 
I don't need to to know this is pretty bad for D, even if the 
proposal is really good.

I'd like to remind everybody of a simple fact: it is impossible 
to write a high quality generic container in D, right now. This 
is because there is no way to explain to the compiler that a 
`const Vector!T` is the same as a `const Vector!(const T)`.

There is no syntactic sugar, no optimization, no static analysis, 
no nothing that can compensate for this, just like it doesn't 
matter how comfortable the seat are on a car which has no wheels.

On the other hand, this will yet again break many tools, setting 
the ecosystem back once again. This same pattern has been 
repeating for at least a decade by now.
May 20 2022
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 20 May 2022 at 11:28:38 UTC, deadalnix wrote:

 On the other hand, this will yet again break many tools, 
 setting the ecosystem back once again.


Yeah, it'll take like an hour to update our custom parsers.
May 20 2022
prev sibling next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Friday, 20 May 2022 at 11:28:38 UTC, deadalnix wrote:

 So I was catching up with he humongous thread. What stroke me 
 in there is that almost everybody is missing the point, but 
 maybe that isn't so surprising, as there is a self selection 
 bias at play.

 I especially noticed this post: 
 https://forum.dlang.org/post/kkmlkebnsbembkispcya forum.dlang.org

 Apparently, we are getting named argument soon. I have no 
 opinion whether this is good or bad, I haven't even read he 
 proposal. But I don't need to to know this is pretty bad for D, 
 even if the proposal is really good.

 I'd like to remind everybody of a simple fact: it is impossible 
 to write a high quality generic container in D, right now. This 
 is because there is no way to explain to the compiler that a 
 `const Vector!T` is the same as a `const Vector!(const T)`.

 There is no syntactic sugar, no optimization, no static 
 analysis, no nothing that can compensate for this, just like it 
 doesn't matter how comfortable the seat are on a car which has 
 no wheels.

 On the other hand, this will yet again break many tools, 
 setting the ecosystem back once again. This same pattern has 
 been repeating for at least a decade by now.


Isn't that a consequence of transitive const though? Allowing one 
to bypass that means getting rid of one of the most distinctive 
features of D 😧

If we get rid of that, then our const will almost become the same 
as C++'s(only `mutable` will be left, ie, logical const)

Is that okay?
May 20 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 20 May 2022 at 12:01:17 UTC, Tejas wrote:

 Isn't that a consequence of transitive const though?


No, it works for built-in arrays. Just the language doesn't let 
you express that for user-defined types.

There's a lot of little gaps the built-in things use magic to 
fill.
May 20 2022
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 20/05/2022 11:28 PM, deadalnix wrote:

 Apparently, we are getting named argument soon. I have no opinion 
 whether this is good or bad, I haven't even read he proposal. But I 
 don't need to to know this is pretty bad for D, even if the proposal is 
 really good.


As a previous author of a named parameter DIP, I can say its a good DIP 
but it doesn't solve a pretty important thing. The ability to access 
template parameters as if they were a member externally.

As Max discovered, its a lot of work to implement. So much technical 
debt and so little refactoring going on. Oh well.


 I'd like to remind everybody of a simple fact: it is impossible to 


write a high quality generic container in D, right now. This is because 
there is no way to explain to the compiler that a `const Vector!T` is 
the same as a `const Vector!(const T)`.

The things that concern me wrt. data structures are:

I can't `` disable const;`` and stop the outer type being able to become 
const. It is a lot of work to prevent it.

Why can't I support const? To iterate, you need to be able to mutate 
state. This includes an iterator (for concurrent iteration + mutation 
support). And of course reference counting.

For data structures, because they must be able to mutate state, const is 
effectively immutable. You can't know if the state is in read only 
memory or not. So the only thing you can do is throw up your hands and 
go, nope not my problem!

This of course becomes a pain if you need to return say a list of 
strings that was computed at the start of a program that will never 
change. But once you return it, anyone can change it. I'm now 
considering copy on write for them wholesale.

All this before we consider lifetime issues *sigh*.
May 20 2022
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 20 May 2022 at 12:59:04 UTC, rikki cattermole wrote:

 Why can't I support const? To iterate, you need to be able to 
 mutate state. This includes an iterator (for concurrent 
 iteration + mutation support). And of course reference counting.


I just want to note that librebindable was created to solve this 
exact problem. I'm gonna do a dconf talk on that, too. (Yay!)

https://code.dlang.org/packages/rebindable We've mostly done 
development on the code in an inhouse repo, so this is a bit 
outdated, but nothing in the internals has changed, as far as I 
can remember. I'm going to do an update of the public repo before 
DConf, add some utility types as examples and so on. But the core 
idea has been surprisingly stable.
May 22 2022
parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 22 May 2022 at 13:46:29 UTC, FeepingCreature wrote:

 On Friday, 20 May 2022 at 12:59:04 UTC, rikki cattermole wrote:

 Why can't I support const? To iterate, you need to be able to 
 mutate state. This includes an iterator (for concurrent 
 iteration + mutation support). And of course reference 
 counting.


 I just want to note that librebindable was created to solve 
 this exact problem. I'm gonna do a dconf talk on that, too. 
 (Yay!)

 https://code.dlang.org/packages/rebindable We've mostly done 
 development on the code in an inhouse repo, so this is a bit 
 outdated, but nothing in the internals has changed, as far as I 
 can remember. I'm going to do an update of the public repo 
 before DConf, add some utility types as examples and so on. But 
 the core idea has been surprisingly stable.


I wonder if it would be easier to use 
[`__traits(getPointerBitmap)`][1] instead of recursion on 
`T.tupleof` to determine the layout of `Rebindable!T`?

[1]: https://dlang.org/spec/traits.html#getPointerBitmap
May 22 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2022 4:28 AM, deadalnix wrote:

 I'd like to remind everybody of a simple fact: it is impossible to write a
high 
 quality generic container in D, right now. This is because there is no way to 
 explain to the compiler that a `const Vector!T` is the same as a `const 
 Vector!(const T)`.


I don't recall anyone ever bringing it up before. Glad you did.

Want to write a proposal for it?
May 20 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 21/05/2022 3:45 PM, Walter Bright wrote:

 I don't recall anyone ever bringing it up before. Glad you did.


Cross referencing:

https://forum.dlang.org/post/nnkuxoiawyvgyrnuesxu forum.dlang.org

https://forum.dlang.org/post/umekbkvomyixeiksgzfd forum.dlang.org
May 20 2022
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 21.05.22 05:45, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 I'd like to remind everybody of a simple fact: it is impossible to 
 write a high quality generic container in D, right now. This is 
 because there is no way to explain to the compiler that a `const 
 Vector!T` is the same as a `const Vector!(const T)`.


 
 I don't recall anyone ever bringing it up before.


I brought it up a number of times. ;) I think the last time was here:
https://forum.dlang.org/post/sk4v9b$2apt$1 digitalmars.com

deadalnix has also talked about this multiple times over the years.


 Glad you did.
 
 Want to write a proposal for it?


Yes, probably needs a DIP. Seems somewhat tricky to get just right. The 
mechanism should be simple and should e.g. allow the wrapping of a 
built-in slice within a templated struct with the same typing behavior.

A pretty simple feature that seems to do the job would be something like:

```d
 structuralSubtyping
struct Slice(T){
     T[] payload;
}
```

Then whenever you need to evaluate a subtyping relationship between 
multiple instantiations of the same  structural-annotated templated 
type, you check that the field layout matches (including field names) 
and that all field types are subtypes of their new type.

There should be a way to do custom introspection (subtype constraints).

```d
 structuralSubtyping!condition
struct Slice(T){
     T[] payload;
}
```

Where "condition" is passed both instantiated types with full qualifiers 
and can do additional checks to possibly maintain typing invariants that 
are not tracked by D's type system alone.

There should also be an unsafe escape hatch to exclude certain members 
from the automated field layout checks, but maybe void* and void[n] are 
good enough for this.

Finally, the magic "strip qualifiers when passing a slice to a function" 
rule should be applied to template types with ` structuralSubtyping`.
May 21 2022
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 May 2022 at 11:39:06 UTC, Timon Gehr wrote:

 Yes, probably needs a DIP. Seems somewhat tricky to get just 
 right. The mechanism should be simple and should e.g. allow the 
 wrapping of a built-in slice within a templated struct with the 
 same typing behavior.

 A pretty simple feature that seems to do the job would be 
 something like:

 ```d
  structuralSubtyping
 struct Slice(T){
     T[] payload;
 }
 ```

 Then whenever you need to evaluate a subtyping relationship 
 between multiple instantiations of the same 
  structural-annotated templated type, you check that the field 
 layout matches (including field names) and that all field types 
 are subtypes of their new type.

 There should be a way to do custom introspection (subtype 
 constraints).

 ```d
  structuralSubtyping!condition
 struct Slice(T){
     T[] payload;
 }
 ```

 Where "condition" is passed both instantiated types with full 
 qualifiers and can do additional checks to possibly maintain 
 typing invariants that are not tracked by D's type system alone.

 There should also be an unsafe escape hatch to exclude certain 
 members from the automated field layout checks, but maybe void* 
 and void[n] are good enough for this.

 Finally, the magic "strip qualifiers when passing a slice to a 
 function" rule should be applied to template types with 
 ` structuralSubtyping`.


While this would allow to do the container thing, I do not 
believe this is the right way to go at it. It has an DIP "do the 
thing" flavor to it. I think not being able to do containers is a 
symptom of a missing piece in the type system, most notably type 
qualifier.

As far as I can tell, what's needed is a for of generics, at 
least for type qualifiers.

I don't pretend to have all the solutions, and I'm sure that the 
combined talent of the community can sort this out if, and that's 
a big if, we are willing to actually focus on what really matters 
here.
May 21 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 21.05.22 15:00, deadalnix wrote:

 On Saturday, 21 May 2022 at 11:39:06 UTC, Timon Gehr wrote:

 Yes, probably needs a DIP. Seems somewhat tricky to get just right. 
 The mechanism should be simple and should e.g. allow the wrapping of a 
 built-in slice within a templated struct with the same typing behavior.

 A pretty simple feature that seems to do the job would be something like:

 ```d
  structuralSubtyping
 struct Slice(T){
     T[] payload;
 }
 ```

 Then whenever you need to evaluate a subtyping relationship between 
 multiple instantiations of the same  structural-annotated templated 
 type, you check that the field layout matches (including field names) 
 and that all field types are subtypes of their new type.

 There should be a way to do custom introspection (subtype constraints).

 ```d
  structuralSubtyping!condition
 struct Slice(T){
     T[] payload;
 }
 ```

 Where "condition" is passed both instantiated types with full 
 qualifiers and can do additional checks to possibly maintain typing 
 invariants that are not tracked by D's type system alone.

 There should also be an unsafe escape hatch to exclude certain members 
 from the automated field layout checks, but maybe void* and void[n] 
 are good enough for this.

 Finally, the magic "strip qualifiers when passing a slice to a 
 function" rule should be applied to template types with 
 ` structuralSubtyping`.


 
 While this would allow to do the container thing, I do not believe this 
 is the right way to go at it.


Well, it works, solves the problem, and most likely has a simple enough 
implementation.


 It has an DIP "do the thing" flavor to it. 
 I think not being able to do containers is a symptom of a missing piece 
 in the type system, most notably type qualifier.
 
 As far as I can tell, what's needed is a for of generics, at least for 
 type qualifiers.
 ...


Of course, that was also on my list of features I wish for:
https://forum.dlang.org/post/sk4v9b$2apt$1 digitalmars.com

Let's say we get generics only for type qualifiers, then you can maybe 
do something like:

struct Slice[qualifier q](T: q(T)){
     q(T)[] payload;
}

But now, even if you can figure out what new sub-language of generic 
parameter annotations you need to fully capture possible subtyping 
relationships between different generic instances, this still does not 
solve the problem that there is magic typing behavior:

class A{}
class B:A{}

static assert(is(const(B)[]:const(A)[]));

static assert(is(Slice!(const(B)):Slice!(const(A))));

I.e., it would need to be generics all the way down, and to get the 
subtyping behavior you want, you'd need annotations to distinguish cases 
like:

```d
struct S[T]{
     T[][] payload;
}

struct S[T]{
     const(T)[] payload;
}

struct S[T]{
     T[] payload;
}

struct S[T]{
     T payload;
}
```

That's something of an endeavor if you want to aim for completeness, so 
I think something like  structuralSubtyping is looking pretty good from 
a usability perspective even if you have generics.


 I don't pretend to have all the solutions, and I'm sure that the 
 combined talent of the community can sort this out if, and that's a big 
 if, we are willing to actually focus on what really matters here.


Does this even qualify as "really matters"? Why is this even blocking 
Phobos containers?
May 22 2022
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 4:39 AM, Timon Gehr wrote:

 https://forum.dlang.org/post/sk4v9b$2apt$1 digitalmars.com


That's a good list, thank you!



 Yes, probably needs a DIP. Seems somewhat tricky to get just right. The 
 mechanism should be simple and should e.g. allow the wrapping of a built-in 
 slice within a templated struct with the same typing behavior.
 
 A pretty simple feature that seems to do the job would be something like:
 
 ```d
  structuralSubtyping
 struct Slice(T){
      T[] payload;
 }
 ```
 
 Then whenever you need to evaluate a subtyping relationship between multiple 
 instantiations of the same  structural-annotated templated type, you check
that 
 the field layout matches (including field names) and that all field types are 
 subtypes of their new type.
 
 There should be a way to do custom introspection (subtype constraints).
 
 ```d
  structuralSubtyping!condition
 struct Slice(T){
      T[] payload;
 }
 ```
 
 Where "condition" is passed both instantiated types with full qualifiers and
can 
 do additional checks to possibly maintain typing invariants that are not
tracked 
 by D's type system alone.
 
 There should also be an unsafe escape hatch to exclude certain members from
the 
 automated field layout checks, but maybe void* and void[n] are good enough for 
 this.
 
 Finally, the magic "strip qualifiers when passing a slice to a function" rule 
 should be applied to template types with ` structuralSubtyping`.


I'm afraid there's not enough here for me to understand it.
May 21 2022
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
https://issues.dlang.org/show_bug.cgi?id=23133
May 21 2022
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 21 May 2022 at 11:39:06 UTC, Timon Gehr wrote:

 On 21.05.22 05:45, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 I'd like to remind everybody of a simple fact: it is 
 impossible to write a high quality generic container in D, 
 right now. This is because there is no way to explain to the 
 compiler that a `const Vector!T` is the same as a `const 
 Vector!(const T)`.


 
 I don't recall anyone ever bringing it up before.


 I brought it up a number of times. ;) I think the last time was 
 here:
 https://forum.dlang.org/post/sk4v9b$2apt$1 digitalmars.com

 deadalnix has also talked about this multiple times over the 
 years.
 [snip]


As Walter says multiple times, if things aren't on bugzilla, then 
they get lost in the shuffle...
May 21 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 May 2022 at 22:11:22 UTC, jmh530 wrote:

 deadalnix has also talked about this multiple times over the 
 years.
 [snip]


 As Walter says multiple times, if things aren't on bugzilla, 
 then they get lost in the shuffle...


Every one of these that qualify as a bug is in bugzilla. Some of 
them are more than a decade old, for instance: 
https://issues.dlang.org/show_bug.cgi?id=6857
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 5:19 PM, deadalnix wrote:

 Every one of these that qualify as a bug is in bugzilla. Some of them are more 
 than a decade old, for instance: https://issues.dlang.org/show_bug.cgi?id=6857


I welcome any help with these.

Also, it's fine to post a list of the issues you feel are important bug are 
neglected. If you keep around a list of these, you can repost the list any time 
necessary.

BTW, 6857 is likely a breaking change. What to do about that?
May 21 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 May 2022 at 01:37:55 UTC, Walter Bright wrote:

 BTW, 6857 is likely a breaking change. What to do about that?


I would say it is not a breaking change. I write contracts so 
that I know when my code is broken. When the compiler fails to do 
so, then it is a bug in the compiler. If my code breaks because 
this is fixed, then that means that my code **always was broken 
to begin with**. I'd rather know about it.
May 22 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 6:34 AM, deadalnix wrote:

 I would say it is not a breaking change. I write contracts so that I know when 
 my code is broken. When the compiler fails to do so, then it is a bug in the 
 compiler. If my code breaks because this is fixed, then that means that my
code 
 **always was broken to begin with**. I'd rather know about it.


Fair enough, but I've fixed many broken features to find that people depended
on 
them, and then complained that D is unstable.
May 22 2022
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 23 May 2022 at 03:13:29 UTC, Walter Bright wrote:

 On 5/22/2022 6:34 AM, deadalnix wrote:

 I would say it is not a breaking change. I write contracts so 
 that I know when my code is broken. When the compiler fails to 
 do so, then it is a bug in the compiler. If my code breaks 
 because this is fixed, then that means that my code **always 
 was broken to begin with**. I'd rather know about it.


 Fair enough, but I've fixed many broken features to find that 
 people depended on them, and then complained that D is unstable.


Does that mean we need to complain more loudly that D is broken? 
;-)

IMO, fear of breaking things is for projects who think they 
already have the most users that they will ever have. If you 
anticipate more people using D in the future, you should not let 
the complaints of current users cause pain for future users.

At any rate, my personal oft-stated opinion is of course that the 
rate of change is too small. (Though I can't complain too loudly, 
since I've not exactly been making a lot of pull requests 
lately...)
May 23 2022
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, May 23, 2022 at 01:46:25PM +0000, FeepingCreature via Digitalmars-d
wrote:
[...]

 IMO, fear of breaking things is for projects who think they already
 have the most users that they will ever have. If you anticipate more
 people using D in the future, you should not let the complaints of
 current users cause pain for future users.
 
 At any rate, my personal oft-stated opinion is of course that the rate
 of change is too small. (Though I can't complain too loudly, since
 I've not exactly been making a lot of pull requests lately...)


Breaking changes is actually a good thing, *provided* users are given an
off-ramp to smoothly migrate to the new way of writing things. (And
also, the mere existence of an off-ramp is not the same thing as an
off-ramp that's obvious to the user or told to him when the breakage
happens -- e.g., if the compiler proposes the new way of writing it.)

I've told before of the deprecation of pointers implicitly converting to
bool, that actually improved my code:

	// Before:
	T* ptr;
	if ((ptr = func()) && ...) { ... }

	// After:
	T* ptr;
	if ((ptr = func()) !is null && ...) { ... } // look, ma! More readable!

This kind of breaking change is welcome.

But breakages that have no workarounds are rather unwelcome.


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are written
after the fact to describe the sorry mess that has gone on before.
May 23 2022
prev sibling next sibling parent reply mee6 <mee6 lookat.me> writes:
On Monday, 23 May 2022 at 13:46:25 UTC, FeepingCreature wrote:

 IMO, fear of breaking things is for projects who think they 
 already have the most users that they will ever have. If you 
 anticipate more people using D in the future, you should not 
 let the complaints of current users cause pain for future users.


I don't think so, I don't want things to break cause I want my 
code to keep working. It's been brought up millions of times but 
D has terrible project management, and it probably never will 
change as the current project maintainers are happy with the way 
things are.

I don't know what to say when you have so many broken features 
that it becomes a regular occurrence that people become dependent 
on your broken features. Obviously something isn't working.
May 23 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 23 May 2022 at 17:30:38 UTC, mee6 wrote:

 I don't think so, I don't want things to break cause I want my 
 code to keep working.


Not all breakages are the same.

Some of the "breakage" I want are places where the compiler 
accepts invalid things according to the spec. Which means your 
code is *currently* broken, just the compiler doesn't tell you.

You also need to consider migration paths and if it is forward or 
backward compatible.
May 23 2022
parent deadalnix <deadalnix gmail.com> writes:
On Monday, 23 May 2022 at 17:39:58 UTC, Adam D Ruppe wrote:

 On Monday, 23 May 2022 at 17:30:38 UTC, mee6 wrote:

 I don't think so, I don't want things to break cause I want my 
 code to keep working.


 Not all breakages are the same.

 Some of the "breakage" I want are places where the compiler 
 accepts invalid things according to the spec. Which means your 
 code is *currently* broken, just the compiler doesn't tell you.

 You also need to consider migration paths and if it is forward 
 or backward compatible.


Indeed.
May 23 2022
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 23 May 2022 at 17:30:38 UTC, mee6 wrote:

 On Monday, 23 May 2022 at 13:46:25 UTC, FeepingCreature wrote:

 IMO, fear of breaking things is for projects who think they 
 already have the most users that they will ever have. If you 
 anticipate more people using D in the future, you should not 
 let the complaints of current users cause pain for future 
 users.


 I don't think so, I don't want things to break cause I want my 
 code to keep working. It's been brought up millions of times 
 but D has terrible project management, and it probably never 
 will change as the current project maintainers are happy with 
 the way things are.


Right, but most of all I want my *future* code to be better!

Is there more future D code or more present D code? Which is more 
important? That's the relevant question, I think.
May 23 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 May 2022 at 17:59:11 UTC, FeepingCreature wrote:

 Right, but most of all I want my *future* code to be better!


Easy to solve, use 4 branches: old, stable, nextgen, 
experimental. Every 3 years advance stable to old, nextgen to 
stable. Features move from experimental to nextgen when completed 
and tested. Old gets critical security updates, but not much 
more. Stable gets fixes.

Then everyone has 3+ years to upgrade their codebase. If they 
want faster use nextgen or experimental.

And use semver.

No more confusion... and more freedom.
May 23 2022
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 23 May 2022 at 18:39:10 UTC, Ola Fosheim Grøstad wrote:

 On Monday, 23 May 2022 at 17:59:11 UTC, FeepingCreature wrote:

 Right, but most of all I want my *future* code to be better!


 Easy to solve, use 4 branches: old, stable, nextgen, 
 experimental. Every 3 years advance stable to old, nextgen to 
 stable. Features move from experimental to nextgen when 
 completed and tested. Old gets critical security updates, but 
 not much more. Stable gets fixes.

 Then everyone has 3+ years to upgrade their codebase. If they 
 want faster use nextgen or experimental.

 And use semver.

 No more confusion... and more freedom.


- Programmer effort spread over four branches
- Every bugfix has to be rebased three times
- Three years?! We'd have gotten templates in stable in 2008!
- If something is annoying, do it less often; if something is 
painful, do it *more* often.

Honestly, I don't understand this. We get maybe one or two bugs 
from DMD updates every half-a-year. What's the issues that cause 
so much upgrade costs?
May 23 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 06:02:23 UTC, FeepingCreature wrote:

 - Every bugfix has to be rebased three times


No, you freeze nextgen 1 year before release and focus on polish.

Different people on experimental and nextgen. Experimental is for 
new features (more than one branch), nextgen is for integration.

It should not be much different from what you have with a solid 
process.


 Honestly, I don't understand this. We get maybe one or two bugs 
 from DMD updates every half-a-year. What's the issues that 
 cause so much upgrade costs?


You are hardcore. Many D users take breaks, then come back and 
ask for a stable branch. If you want breaking changes you need a 
buffer.

There are virtually no breaking changes in popular languages 
people are used to: c++, go, python, javascript etc
May 24 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2022 10:30 AM, mee6 wrote:

 I don't know what to say when you have so many broken features that it becomes
a 
 regular occurrence that people become dependent on your broken features. 
 Obviously something isn't working.


D is hardly unique in that aspect.

I've often had to deal with complaints that C code developed with Microsoft 
C/C++ wouldn't compile with my compiler, because MSC implemented the language 
contrary to the spec. I've seen it in Javascript, too, when I wrote Dscript.
May 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2022 6:46 AM, FeepingCreature wrote:

 IMO, fear of breaking things is for projects who think they already have the 
 most users that they will ever have. If you anticipate more people using D in 
 the future, you should not let the complaints of current users cause pain for 
 future users.


Fixes for outright bugs that wind up breaking peoples' code is an unfortunate 
cost, but one we'll just have to bear.



 At any rate, my personal oft-stated opinion is of course that the rate of
change 
 is too small. (Though I can't complain too loudly, since I've not exactly been 
 making a lot of pull requests lately...)


Everyone has their own must-have favorite enhancement request. Unfortunately, 
they're all different!
May 24 2022
parent forkit <forkit gmail.com> writes:
On Tuesday, 24 May 2022 at 17:55:11 UTC, Walter Bright wrote:

 .. ....
 Everyone has their own must-have favorite enhancement request. 
 Unfortunately, they're all different!


This is *not* a new dilemma in a free and open community.

This is why those who claim to represent the community, need to 
prioritse their focus on those things that are likely to meet the 
needs of the majority of the community.

Which is not saying you should not seek to meet the needs of the 
few.

But when you're focus is on the needs of the few, at the expense 
of the needs of the majority, well....as we here in Australia 
have just demonstrated (in our recent election).. we throw you 
out ;-)
May 24 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2022 4:28 AM, deadalnix wrote:

 What stroke me in there is that 
 almost everybody is missing the point, but maybe that isn't so surprising, as 
 there is a self selection bias at play.


But you don't say what the point is!
May 20 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 May 2022 at 03:55:41 UTC, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 What stroke me in there is that almost everybody is missing 
 the point, but maybe that isn't so surprising, as there is a 
 self selection bias at play.


 But you don't say what the point is!


Complete what you’ve got. No shortcuts or hacks or 
easy-to-add-stuff that doesnt move the needle.

Don’t add more stuff that isnt strictly needed and avoid 
increasing instability and incomplete features.

Get to a stable state so that it becomes possible to implement an 
alternative and tooling.

Focus on retention, stability, tooling.

Focus on conversion and measure when people fall off the 
bandwagon and why. Installation failure? Tutorial shortcomings? 
Didnt find the help forum? Failed to set up IDE? Found the IDE 
experience confusing? Didnt find his way in the documentation?

Measure, measure, measure...
May 20 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 May 2022 at 05:48:59 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 21 May 2022 at 03:55:41 UTC, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 What stroke me in there is that almost everybody is missing 
 the point, but maybe that isn't so surprising, as there is a 
 self selection bias at play.


 But you don't say what the point is!


 Complete what you’ve got. No shortcuts or hacks or 
 easy-to-add-stuff that doesnt move the needle.

 Don’t add more stuff that isnt strictly needed and avoid 
 increasing instability and incomplete features.

 Get to a stable state so that it becomes possible to implement 
 an alternative and tooling.

 Focus on retention, stability, tooling.

 Focus on conversion and measure when people fall off the 
 bandwagon and why. Installation failure? Tutorial shortcomings? 
 Didnt find the help forum? Failed to set up IDE? Found the IDE 
 experience confusing? Didnt find his way in the documentation?

 Measure, measure, measure...


All good advices. Really the most important one is the first one: 
"Complete what you’ve got."

We've got a ton of good stuff in D, but we keep adding more 
rather than making sure that what we have is really good.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 6:02 AM, deadalnix wrote:

 We've got a ton of good stuff in D, but we keep adding more rather than making 
 sure that what we have is really good.


I can't help but think this is a bit of a quixotic quest. In mathematics, of 
course, one strives for 100%. But in engineering, one goes for the 95% that is 
at the center, not the edges.

For example, ImportC can *never* be 100% for various reasons. That doesn't mean 
it can't still be immensely useful.

Windows isn't 100%, my iPhone isn't 100%, my car isn't 100%, etc. But they're 
still very usable.

There isn't any software in active use on the planet that is 100%, that's why 
there are endless updates to it.

We have only so many chips we can play. We can place them on fixing bugs,
adding 
new stuff, improving old features, etc. I try to prioritize them by what is
most 
effective for the most number of people. Inevitably, some people will find we 
choose wrongly.

All I can suggest is keep making a case for the things you want, and most 
importantly, *why* they are important.
May 21 2022
next sibling parent reply mee6 <mee6 lookat.me> writes:
On Saturday, 21 May 2022 at 20:02:22 UTC, Walter Bright wrote:

 I try to prioritize them by what is most effective for the most 
 number of people. Inevitably, some people will find we choose 
 wrongly.


Do you have hard numbers on that? IIRC there's only been one 
survey done for the community and almost all the most desired 
features from it aren't implemented.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 1:30 PM, mee6 wrote:

 Do you have hard numbers on that? IIRC there's only been one survey done for
the 
 community and almost all the most desired features from it aren't implemented.


No, I don't have hard numbers. There's always selection bias in self-reporting 
of desired features. I admit to using judgement to decide what to do.

For example, many years ago, only one person asked for User Defined Attributes 
(Manu). He made a compelling case for it. I implemented it. The result was a
lot 
of pushback from the community.

But it has turned out to be a very well liked and used feature.

Of course, things don't always work out so well. D has some features I wish
we'd 
never done.

ImportC is another one that has been met with a lot of skepticism. I have faith 
in it, and we'll see if I'm right or wrong about it.
May 21 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 May 2022 at 21:24:33 UTC, Walter Bright wrote:

 I implemented it. The result was a lot of pushback from the 
 community.


You implemented *some* of it.

The part I specifically wanted wasn't released until September 
2018

https://dlang.org/changelog/2.082.0.html#uda-function-parameters


I don't recall when the basic UDAs were added and I can't find it 
searching the changelog right now, but if memory serves, it was 
about 2013 (which is late enough that I already had other 
alternatives to them implemented in my web server library), but 
there was a gap of *several years* between your initial 
implementation and it actually covering all the bases to make it 
compelling.


This is a good example of the overall point: so many things are 
announced with much fanfare as soon as they do the bare minimum 
of functionality....... then it sits at bare minimum for an 
unspecified amount of time before it reaches the point where it 
is actually useful, if it ever reaches that point.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 2:41 PM, Adam D Ruppe wrote:

 On Saturday, 21 May 2022 at 21:24:33 UTC, Walter Bright wrote:

 I implemented it. The result was a lot of pushback from the community.


 
 You implemented *some* of it.


I implemented all of the specified functionality.



 The part I specifically wanted wasn't released until September 2018
 
 https://dlang.org/changelog/2.082.0.html#uda-function-parameters
 
 
 I don't recall when the basic UDAs were added and I can't find it searching
the 
 changelog right now, but if memory serves, it was about 2013 (which is late 
 enough that I already had other alternatives to them implemented in my web 
 server library), but there was a gap of *several years* between your initial 
 implementation and it actually covering all the bases to make it compelling.
 
 
 This is a good example of the overall point: so many things are announced with 
 much fanfare as soon as they do the bare minimum of functionality....... then
it 
 sits at bare minimum for an unspecified amount of time before it reaches the 
 point where it is actually useful, if it ever reaches that point.


UDAs found plenty of uses immediately. The parameters feature was clearly an 
enhancement, not a missing thing. And yes, it was a good enhancement.
May 21 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 May 2022 at 22:33:05 UTC, Walter Bright wrote:

 I implemented all of the specified functionality.


Are you gonna make me dig up the original posts?

I was part of those original discussions with my use cases, one 
of which was specifically putting it on parameters.

Not that anybody in D's leadership ever listens to me anyway.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 3:59 PM, Adam D Ruppe wrote:

 On Saturday, 21 May 2022 at 22:33:05 UTC, Walter Bright wrote:

 I implemented all of the specified functionality.


 
 Are you gonna make me dig up the original posts?
 
 I was part of those original discussions with my use cases, one of which was 
 specifically putting it on parameters.


You asked for a superset of what was specified.



 Not that anybody in D's leadership ever listens to me anyway.


I'm sorry about giving that impression, but I literally cannot remotely do what 
everyone asks me to. I'm not Microsoft with 10,000 engineers at my command. And 
your request *did* get eventually implemented.

For another example, `noreturn` was implemented by other than me. It turns out 
to be incomplete. It's now in my lap to fix it. What priority should that get?
May 21 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 22 May 2022 at 03:37:32 UTC, Walter Bright wrote:

 I'm sorry about giving that impression, but I literally cannot 
 remotely do what everyone asks me to. I'm not Microsoft with 
 10,000 engineers at my command. And your request *did* get 
 eventually implemented.


You could have those 10000 engineers at your disposal but they 
wouldn't even know what to do. They would just sit idling or play 
computer games their entire days. In order make people move you 
need to have a clear vision, write architecture documents, write 
work packages and so forth which you or no one in the D 
management does.

Right now people in the D project don't even know what to do or 
implement. Should D have co-routines or should async/await be 
implemented? Then we need a document that explains to everybody 
what needs to be implemented so people can go pick a certain work 
package they want to implement.

The D project consist mostly of coders who just start right away, 
which was obvious with your importC which came out of nowhere. 
Now, I don't demand that everybody should be full seasoned 
managers but the D project certainly lacks these types of people. 
Also people who perhaps want to step away from coding and write 
architecture/design documents would help.
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 2:58 AM, IGotD- wrote:

 Right now people in the D project don't even know what to do or implement. 


They can visit bugzilla, pick anything open, and work on it.


 Should D have co-routines or should async/await be implemented? Then we need 


a document that explains to everybody what needs to be implemented so people
can 
go pick a certain work package they want to implement.

I've suggested many times that someone should work on async/await. You're free 
to contribute there, too.
May 24 2022
next sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 24 May 2022 at 17:25:16 UTC, Walter Bright wrote:

 Should D have co-routines or should async/await be


 implemented? Then we need a document that explains to everybody 
 what needs to be implemented so people can go pick a certain 
 work package they want to implement.

 I've suggested many times that someone should work on 
 async/await. You're free to contribute there, too.


I don't think this is enough. "You are free to contribute" is not 
enough to motivate people. What is needed are work packages and 
also design documents so that they know the details what to 
implement. Having this also states the goals and vision of D.

Freely implementing something is no guarantee that it will be 
merged to the D main branch. A stated goal and implementation 
according to the design guarantees this which motivates people to 
contribute.

Not having written goals, designs and what should be done will 
just end up in a Half Life 3 situation.
May 24 2022
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 24 May 2022 at 17:25:16 UTC, Walter Bright wrote:

 On 5/24/2022 2:58 AM, IGotD- wrote:

 Right now people in the D project don't even know what to do 
 or implement.


 They can visit bugzilla, pick anything open, and work on it.

 [snip]


There are only so many people who have the knowledge needed to 
fix DMD bugs...makes sense for those capable and interested in 
working on DMD to coordinate on what are the most important (TM) 
bugs/things to work on...
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 10:58 AM, jmh530 wrote:

 There are only so many people who have the knowledge needed to fix DMD 
 bugs...makes sense for those capable and interested in working on DMD to 
 coordinate on what are the most important (TM) bugs/things to work on...


There's something for every skill level:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=240744&query_format=advanced
May 24 2022
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Sunday, 22 May 2022 at 03:37:32 UTC, Walter Bright wrote:

 For another example, `noreturn` was implemented by other than 
 me. It turns out to be incomplete. It's now in my lap to fix it.


That's the opposite of what happened. You kicked off the 
implementation around March 2021:
https://github.com/dlang/dmd/pulls?q=is%3Aclosed+is%3Apr+author%3Awalterbright+DIP1034

Then you abandoned it for ImportC and it got released in an 
incomplete state, without a preview switch.

It was actually Florian who stepped up and started fixing the 
issues that were pouring in because of that:

https://github.com/dlang/dmd/pulls?q=is%3Aclosed+is%3Apr+author%3Amoonlightsentinel+noreturn+

But there's still a lot more to go before DIP1034 is properly 
implemented.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 3:43 AM, Dennis wrote:

 That's the opposite of what happened. You kicked off the implementation around 
 March 2021:
 https://github.com/dlang/dmd/pulls?q=is%3Aclosed+is%3Apr+author%3A
alterbright+DIP1034 


I stand corrected.
May 24 2022
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 21 May 2022 at 21:24:33 UTC, Walter Bright wrote:


 For example, many years ago, only one person asked for User 
 Defined Attributes (Manu). He made a compelling case for it. I 
 implemented it. The result was a lot of pushback from the 
 community.


I'll tell you why we didn't ask for them. We were brain-washed 
into believing that the language needed to be minimalistic, 
avoided feature creep, was easy for a compiler writer to 
implement, etc. So, we just tried to emulate them with static 
members in silence and pain. The compelling cases for UDAs have 
been demonstrated by other languages long before Manu.
May 22 2022
parent zjh <fqbqrr 163.com> writes:
On Sunday, 22 May 2022 at 10:18:11 UTC, Max Samukha wrote:

 Manu.


`Manu` has another `...` proposal, which is very easy to use.
And it is `orthogonal` to the vector.
May 22 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 May 2022 at 20:02:22 UTC, Walter Bright wrote:

 For example, ImportC can *never* be 100% for various reasons. 
 That doesn't mean it can't still be immensely useful.


You don’t have to do it all by yourself. This isn’t a straight 
forward engineering problem. It takes some innovation and 
thinking in terms of classification as well as parsing.

It takes a little bit of research and perhaps borrowing some 
ideas from others. This problem needs some cooperation and 
prototyping I think.

One should be able to get macro expansion to 99.9%, if you done 
in situ, for typical C APIs.
May 21 2022
prev sibling parent reply mw <mingwu gmail.com> writes:
On Saturday, 21 May 2022 at 20:02:22 UTC, Walter Bright wrote:

 On 5/21/2022 6:02 AM, deadalnix wrote:

 We've got a ton of good stuff in D, but we keep adding more 
 rather than making sure that what we have is really good.


 I can't help but think this is a bit of a quixotic quest.


This has been discussed so many times:

1) Freeze the current features, and release as the final version 
D2 (i.e put into maintenance mode, only have bug fix update, not 
any more new language features). I think any serious enterprise 
users want language/library stability.


2) all future work going to D3, for you to add / experiment new 
language features; and for adventurous users to play with it.


So, one more time, how about D3? Walter, do you hear?
May 21 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 3:28 PM, mw wrote:

 Walter, do you hear?


What to do about people who want only bug fixes, but please include their 
favorite enhancement request? And what if fixing a bug requires a new or
changed 
feature? Or who wants a recent feature backported into an old release?

There aren't obvious answers.

There's also only one of me. Anyone is free to do any of those things. That's 
why we're on git. We can use the help.
May 21 2022
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 21 May 2022 at 03:55:41 UTC, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 What stroke me in there is that almost everybody is missing 
 the point, but maybe that isn't so surprising, as there is a 
 self selection bias at play.


 But you don't say what the point is!


I believe, from what he said in other thread, that in his opinion 
D should bundle changes that require tooling updates so that they 
happen only once per every few years.

I personally don't agree with that. I fear that having to wait 
for the biannual or so release day to have any significant 
language improvements released would frustate contributors. And 
it would drastically slow the feedback loop, with regards to 
experience with the new features.
May 21 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 21 May 2022 at 09:08:10 UTC, Dukc wrote:

 I believe, from what he said in other thread, that in his 
 opinion D should bundle changes that require tooling updates so 
 that they happen only once per every few years.

 I personally don't agree with that. I fear that having to wait 
 for the biannual or so release day to have any significant 
 language improvements released would frustate contributors. And 
 it would drastically slow the feedback loop, with regards to 
 experience with the new features.


I think maybe the better answer is, make tooling part of D's CI 
pipelines.

We have the project tester to make sure we don't break D 
projects, and it does a pretty good job. If we care about 
tooling, it stands to reason that we should have a tooling tester 
too.
May 21 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 4:26 AM, Paul Backus wrote:

 We have the project tester to make sure we don't break D projects, and it does
a 
 pretty good job. If we care about tooling, it stands to reason that we should 
 have a tooling tester too.


The project tester has indeed been very successful.
May 21 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 May 2022 at 03:55:41 UTC, Walter Bright wrote:

 On 5/20/2022 4:28 AM, deadalnix wrote:

 What stroke me in there is that almost everybody is missing 
 the point, but maybe that isn't so surprising, as there is a 
 self selection bias at play.


 But you don't say what the point is!


I do. I have done so repeatedly for a decade now.

There are holes in the foundations of the languages. These hole 
prevent basic things from being possible at all. For instance, 
containers.

But the focus has consistently been on other feature which are 
nice to have. The problem, is that it doesn't matter how much 
nice to have things you have - and I'll grant you that D has more 
than most on this front - if there are holes in the foundations.

Lately, the focus has been on named argument, tuples, ImportC, 
and a few other things. All good things. There are a couple of 
these holes, but really, the limus test shoudl be: can i write a 
custom container class that behaves lice builtin slice do? If so, 
then we are probably in good shape. If not, then literally 
anything else we add to the language is a net negative as it 
increase complexity without tackling the bottleneck.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 4:54 AM, deadalnix wrote:

 There are holes in the foundations of the languages. These hole prevent basic 
 things from being possible at all. For instance, containers.



Ok, can you please provide a comprehensive list of these holes?
May 21 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 May 2022 at 19:46:48 UTC, Walter Bright wrote:

 On 5/21/2022 4:54 AM, deadalnix wrote:

 There are holes in the foundations of the languages. These 
 hole prevent basic things from being possible at all. For 
 instance, containers.



 Ok, can you please provide a comprehensive list of these holes?


I've done so a gazilion time, and the fact you cannot think of 
one is the focus problem I'm talking about. Just on type 
qualifiers:
  - Transitivity of type qualifier doesn't play nice with 
template. There is no way to tell the compiler that a `const 
Tpl!T` actually is a `const Tpl!(const T)`. As a result, no 
container library is possible and ranges have serious problem 
when it come to qualifiers too.
  - delegates break constness guarantees as the type qualifier ont 
he context is not tracked and/or checked.
  - closure break constness guarantee, as I can mutate an 
immutable variable visible in a closure when iterating in a loop.
  - There is no way to build a shared object without breaking the 
type system.
  - shared is supposed to be explicit, yet all objects have a 
monitor - granted this one is not broken per se, but a major WTF.
  - synchronized shared object cannot provide the guarantee they 
are supposed to because there is no adequate escape analysis.
  - const/immutable doesn't play nice with reference types (the 
qualify both the object and the reference), making the type 
qualifier system pretty much unworkable with OOP style code.

It's just on top of my head, but I'm sure there is more.

Now, don't get me wrong, some of these are hard problems. But the 
more we add to the pile of stuff we have, the harder they become 
to solve.
May 21 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2022 5:14 PM, deadalnix wrote:

 On Saturday, 21 May 2022 at 19:46:48 UTC, Walter Bright wrote:

 On 5/21/2022 4:54 AM, deadalnix wrote:

 There are holes in the foundations of the languages. These hole prevent basic 
 things from being possible at all. For instance, containers.



 Ok, can you please provide a comprehensive list of these holes?


 
 I've done so a gazilion time, and the fact you cannot think of one is the
focus 
 problem I'm talking about.


The trouble is, posting these on the n.g. is not a good method, as the n.g. is 
ephemeral and no, I don't read every posting. Nobody can. When someone says "it 
was posted on the n.g. some time ago" there's just no way to deal with that.
The 
n.g. is like 15 years worth of receipts thrown down the stairs into the
basement 
to be forgotten.

A better way is to think them through, and post enhancement requests on 
Bugzilla. That's what it's for. Then, when someone says "what about XXX that I 
proposed" he can point to the bugzilla issue. If anyone has anything
substantive 
to say about it he can attach comments to that issue.

A more formal way is to create DIPs for them.



 Just on type qualifiers:
   - Transitivity of type qualifier doesn't play nice with template. There is
no 
 way to tell the compiler that a `const Tpl!T` actually is a `const Tpl!(const 
 T)`. As a result, no container library is possible and ranges have serious 
 problem when it come to qualifiers too.


This needs a lot more fleshing out about what exactly is wrong and why.


   - delegates break constness guarantees as the type qualifier ont he context
is 
 not tracked and/or checked.


This should be a bug report in bugzilla with an example.


   - closure break constness guarantee, as I can mutate an immutable variable 
 visible in a closure when iterating in a loop.


This should be a bug report in bugzilla with an example.


   - There is no way to build a shared object without breaking the type system.


That's correct. It's intended to be done with  system code. I don't know any
way 
out of that, if you know of one, please make an enhancement request. (You can't 
write a storage allocator in  safe code, either.)


   - shared is supposed to be explicit, yet all objects have a monitor -
granted 
 this one is not broken per se, but a major WTF.


The monitor idea turned out to be a bad idea. I recommend simply ignoring it.


   - synchronized shared object cannot provide the guarantee they are supposed
to 
 because there is no adequate escape analysis.


I don't know what this means.


   - const/immutable doesn't play nice with reference types (the qualify both
the 
 object and the reference), making the type qualifier system pretty much 
 unworkable with OOP style code.


This needs to be a lot more specific. "doesn't play nice" is just not helpful.


 Now, don't get me wrong, some of these are hard problems. But the more we add
to 
 the pile of stuff we have, the harder they become to solve.


Thank you for writing the list.
May 21 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.05.22 03:26, Walter Bright wrote:

 On 5/21/2022 5:14 PM, deadalnix wrote:

 On Saturday, 21 May 2022 at 19:46:48 UTC, Walter Bright wrote:

 On 5/21/2022 4:54 AM, deadalnix wrote:

 There are holes in the foundations of the languages. These hole 
 prevent basic things from being possible at all. For instance, 
 containers.



 Ok, can you please provide a comprehensive list of these holes?


 I've done so a gazilion time, and the fact you cannot think of one is 
 the focus problem I'm talking about.


 
 The trouble is, posting these on the n.g. is not a good method, as the 
 n.g. is ephemeral and no, I don't read every posting. Nobody can. When 
 someone says "it was posted on the n.g. some time ago" there's just no 
 way to deal with that. The n.g. is like 15 years worth of receipts 
 thrown down the stairs into the basement to be forgotten.
 
 A better way is to think them through, and post enhancement requests on 
 Bugzilla. That's what it's for. Then, when someone says "what about XXX 
 that I proposed" he can point to the bugzilla issue. If anyone has 
 anything substantive to say about it he can attach comments to that issue.
 
 A more formal way is to create DIPs for them.
 
 

 Just on type qualifiers:
   - Transitivity of type qualifier doesn't play nice with template. 
 There is no way to tell the compiler that a `const Tpl!T` actually is 
 a `const Tpl!(const T)`. As a result, no container library is possible 
 and ranges have serious problem when it come to qualifiers too.


 
 This needs a lot more fleshing out about what exactly is wrong and why.
 ...


Instances of the same struct/class template are independent types 
without any relationship. Different types of slices (for example) are not.


   - delegates break constness guarantees as the type qualifier ont he 
 context is not tracked and/or checked.


 
 This should be a bug report in bugzilla with an example.
 ...


The bug report is 15 years old:

https://issues.dlang.org/show_bug.cgi?id=1983

Example:

```d
class C{
     int x;
     void delegate() dg;
     this(){
         dg = (){ x++; }; // mutate x
     }
}

void main(){
     const c=new C();
     auto old_x=c.x;
     c.dg(); // accepts invalid
     auto new_x=c.x;
     assert(old_x==new_x);
}
```

Solution: Properly type check the context pointer, for example it should 
not be possible to call a `const(void delegate())` dg because the 
context is const, but the function pointer accepts a mutable context.


   - closure break constness guarantee, as I can mutate an immutable 
 variable visible in a closure when iterating in a loop.


 
 This should be a bug report in bugzilla with an example.
 ...


Another 15 year old bug report:

https://issues.dlang.org/show_bug.cgi?id=2043

Example:

```d
void main(){
     int delegate()[] dgs;
     foreach(i;0..2){
         immutable int k=i;
         dgs~=()=>k;
     }
     assert(dgs[0]()==0&&dgs[1]()==1); // fails
}
```

Solution: If a delegate closes over a loop-local variable, create one 
context per loop iteration. (The `immutable` in the example above just 
demonstrates that what's going on is memory corruption, it should still 
work the same way if there is no `immutable`.)


 ... >

   - const/immutable doesn't play nice with reference types (the 
 qualify both the object and the reference), making the type qualifier 
 system pretty much unworkable with OOP style code.


 
 This needs to be a lot more specific. "doesn't play nice" is just not 
 helpful.
 ...


There is no way to declare a tail-immutable class reference.

immutable(int)* <- can rebind the reference, can't assign to value

immutable(Class) <- can't rebind the reference
Class <- can rebind the reference, can assign to value


 Now, don't get me wrong, some of these are hard problems. But the more 
 we add to the pile of stuff we have, the harder they become to solve.


 
 Thank you for writing the list.


Maybe we can bump the priority on the bugzilla issues?
May 22 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 3:37 AM, Timon Gehr wrote:

 Maybe we can bump the priority on the bugzilla issues?


Thanks for providing bugzilla references. They are very helpful when bringing
up 
issues on the n.g.

My plan after ImportC has reached a certain point is to go through every issue 
on bugzilla marked with the "safe" keyword. (Of course, anyone else can, too.)

One of the issues you posted is marked with "safe", the other wasn't, so I
added 
"safe" to it.
May 23 2022
parent forkit <forkit gmail.com> writes:
On Tuesday, 24 May 2022 at 04:58:00 UTC, Walter Bright wrote:

 ...
 ....
 My plan after ImportC has reached a certain point is to go 
 through every issue on bugzilla marked with the "safe" keyword. 
 (Of course, anyone else can, too.)
 ...
 ....


This is great news! We all really need your talent re-focused 
into that area.

And... being able to further promote D's ' safe', will likely go 
a long way (than ImportC perhaps) in making D more.. umm... 
'popular'.
May 23 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 3:37 AM, Timon Gehr wrote:

 Just on type qualifiers:
   - Transitivity of type qualifier doesn't play nice with template. There is 
 no way to tell the compiler that a `const Tpl!T` actually is a `const 
 Tpl!(const T)`. As a result, no container library is possible and ranges have 
 serious problem when it come to qualifiers too.


 This needs a lot more fleshing out about what exactly is wrong and why.
 ...


 
 Instances of the same struct/class template are independent types without any 
 relationship. Different types of slices (for example) are not.


Illuminating examples, please.



 There is no way to declare a tail-immutable class reference.
 
 immutable(int)* <- can rebind the reference, can't assign to value
 
 immutable(Class) <- can't rebind the reference
 Class <- can rebind the reference, can assign to value


Should file an Enhancement Request on Bugzilla.
May 23 2022
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.05.22 07:00, Walter Bright wrote:

 On 5/22/2022 3:37 AM, Timon Gehr wrote:

 Just on type qualifiers:
   - Transitivity of type qualifier doesn't play nice with template. 
 There is no way to tell the compiler that a `const Tpl!T` actually 
 is a `const Tpl!(const T)`. As a result, no container library is 
 possible and ranges have serious problem when it come to qualifiers 
 too.


 This needs a lot more fleshing out about what exactly is wrong and why.
 ...


 Instances of the same struct/class template are independent types 
 without any relationship. Different types of slices (for example) are 
 not.


 
 Illuminating examples, please.
 ...


For containers: Just consider a struct wrapping a built-in slice.

struct Slice(T){
     T[] slice;
}

T[] is a subtype of const(T)[], but Slice!T is not a subtype of 
Slice!(const(T)). In general this cannot be guaranteed, but containers 
may need to be able to allow this kind of conversions.


For ranges:

E.g., here, x is a const slice and can be mapped. The resulting const 
value cannot be used as a range anymore.


```d
import std.algorithm;
void main(){
     const x=[1,2,3,4];
     const y=x.map!(v=>2*v); // ok
     const z=y.map!(v=>2*v); // error
}
```

This kind of thing should just work, but there is no way to strip away 
the topmost const for a MapResult.

(There is probably an unrelated Phobos bug as well, as the error happens 
in the guts of Phobos.)



 

 There is no way to declare a tail-immutable class reference.

 immutable(int)* <- can rebind the reference, can't assign to value

 immutable(Class) <- can't rebind the reference
 Class <- can rebind the reference, can assign to value


 
 Should file an Enhancement Request on Bugzilla.


There's e.g. this one: https://issues.dlang.org/show_bug.cgi?id=5325
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 4:21 PM, Timon Gehr wrote:

 For containers: Just consider a struct wrapping a built-in slice.
 
 struct Slice(T){
      T[] slice;
 }
 
 T[] is a subtype of const(T)[], but Slice!T is not a subtype of 
 Slice!(const(T)). In general this cannot be guaranteed, but containers may
need 
 to be able to allow this kind of conversions.


What about:

     struct Slice(T) { T[] slice; int* p; }

? A const applied to T will not affect int*, but if the const automatically was 
transferred to Slice, it would, and that would be wrong. It seems you're asking 
for a special case, and as we all lament, special cases lead to corner cases 
with special problems.



 For ranges:
 
 E.g., here, x is a const slice and can be mapped. The resulting const value 
 cannot be used as a range anymore.
 
 
 ```d
 import std.algorithm;
 void main(){
      const x=[1,2,3,4];
      const y=x.map!(v=>2*v); // ok
      const z=y.map!(v=>2*v); // error
 }
 ```
 
 This kind of thing should just work, but there is no way to strip away the 
 topmost const for a MapResult.


const(int**) p;
cast()(p) produces a const(int*)*

I.e. cast() strips the "head" qualifiers.




 There is no way to declare a tail-immutable class reference.

 immutable(int)* <- can rebind the reference, can't assign to value

 immutable(Class) <- can't rebind the reference
 Class <- can rebind the reference, can assign to value


 Should file an Enhancement Request on Bugzilla.


 
 There's e.g. this one: https://issues.dlang.org/show_bug.cgi?id=5325


thank you
May 24 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 01:40, Walter Bright wrote:

 On 5/24/2022 4:21 PM, Timon Gehr wrote:

 For containers: Just consider a struct wrapping a built-in slice.

 struct Slice(T){
      T[] slice;
 }

 T[] is a subtype of const(T)[], but Slice!T is not a subtype of 
 Slice!(const(T)). In general this cannot be guaranteed, but containers 
 may need to be able to allow this kind of conversions.


 
 What about:
 
      struct Slice(T) { T[] slice; int* p; }
 
 ? A const applied to T will not affect int*, but if the const 
 automatically was transferred to Slice, it would, and that would be 
 wrong. It seems you're asking for a special case, and as we all lament, 
 special cases lead to corner cases with special problems.
 ...


Not really. What's needed is some feature that _allows_ implementing a 
correct slice wrapper. I am not asking for the slice wrapper above to do 
the right thing by default.


 

 For ranges:

 E.g., here, x is a const slice and can be mapped. The resulting const 
 value cannot be used as a range anymore.


 ```d
 import std.algorithm;
 void main(){
      const x=[1,2,3,4];
      const y=x.map!(v=>2*v); // ok
      const z=y.map!(v=>2*v); // error
 }
 ```

 This kind of thing should just work, but there is no way to strip away 
 the topmost const for a MapResult.


 
 const(int**) p;
 cast()(p) produces a const(int*)*
 
 I.e. cast() strips the "head" qualifiers.
 ...


It often strips more than that.

struct S(T){ T* p; }

const(S!int) s;
auto t=cast()s; // this is just an S!int, but stripping the "head" 
qualifiers would give us something like an S!(const(int)).

I am not suggesting `cast()` should behave like this by default, because 
as you point out, it is not what you want in general. But there is a 
problem.
May 24 2022
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 22 May 2022 at 01:26:13 UTC, Walter Bright wrote:

 I don't read every posting. Nobody can.


I at least skim every posting and have for over a decade now. I 
do skip fully reading things that are obvious wastes of time 
though.

I'm not the only one too.

It amuses me how many things I've done that people say are 
impossible.


 This needs to be a lot more specific. "doesn't play nice" is 
 just not helpful.


This has been another issue with D's const from day one. Pull 


https://github.com/dlang/dmd/pull/3


You complain that you don't have people at your command. Well, 
there's plenty of people doing plenty of work.

You just keep turning us away.
May 22 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 4:42 AM, Adam D Ruppe wrote:


an 
 attempt to fix it:
 
 https://github.com/dlang/dmd/pull/3
 
 
 You complain that you don't have people at your command. Well, there's plenty
of 
 people doing plenty of work.
 
 You just keep turning us away.


People closing their own PRs means they get forgotten. I didn't close it or
turn 
it away.

The author's comments in it say it is only a partial implementation.

Daniel was the only one to review it. There are many people in the core team.
May 23 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 May 2022 at 01:26:13 UTC, Walter Bright wrote:

 The trouble is, posting these on the n.g. is not a good method, 
 as the n.g. is ephemeral and no, I don't read every posting. 
 Nobody can. When someone says "it was posted on the n.g. some 
 time ago" there's just no way to deal with that. The n.g. is 
 like 15 years worth of receipts thrown down the stairs into the 
 basement to be forgotten.

 A better way is to think them through, and post enhancement 
 requests on Bugzilla. That's what it's for. Then, when someone 
 says "what about XXX that I proposed" he can point to the 
 bugzilla issue. If anyone has anything substantive to say about 
 it he can attach comments to that issue.

 A more formal way is to create DIPs for them.


I wrote DIP, they pretty much got ignored.

I reviewed DIP, pointing how they'd lead to the problems we have 
now, this got ignored too.

Honestly, never again.


   - delegates break constness guarantees as the type qualifier 
 ont he context is not tracked and/or checked.


 This should be a bug report in bugzilla with an example.


https://issues.dlang.org/show_bug.cgi?id=1983

The bug is from 2008. We discussed solution 1:1 in Berlin at one 
of the DConf. I wrote a DIP about how to solve this. If I'm not 
mistaken, Timon also wrote a DIP about this.


   - closure break constness guarantee, as I can mutate an 
 immutable variable visible in a closure when iterating in a 
 loop.


 This should be a bug report in bugzilla with an example.


https://issues.dlang.org/show_bug.cgi?id=2043

Note the first one is from 2008

I think i can stop here because the point is made. All of these 
have long standing bug report for them. Many of these reports are 
10+ years old. Several have DIPs.

The problem here isn't that people aren't reporting these, or 
aren't writing DIP or whatever. It is that they are told to do 
so, waste their time doing that and then they get named argument 
instead.
May 22 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 6:31 AM, deadalnix wrote:

 I wrote DIP, they pretty much got ignored.


Which DIP? When you talk about various issues, it is really really helpful to 
post links to what you are referring to.



 I reviewed DIP, pointing how they'd lead to the problems we have now, this got 
 ignored too.


Which DIP?



 Honestly, never again.


I can understand your feelings about this. But I simply cannot devote 100% to 
everything that people bring up. Sometimes you gotta stand up and shout, and 
sometimes take matters into your own hands.

A lot of D's development comes from people who took matters into their own
hands.



 https://issues.dlang.org/show_bug.cgi?id=1983



 https://issues.dlang.org/show_bug.cgi?id=2043


We have better tools to deal with 2043 today. Note that dgList exceeds the 
lifetime of b, and should fail to compile for that reason.

Let's try it (adding import and  safe and updating the code to D2):
----
import std.stdio;

 safe:

void delegate()[] dgList;

void test() {

         foreach(int i; [1, 2, 3]) {
                 int b = 2;
                 dgList ~= { writeln(b); };
                 writeln(&b); // b will be the *same* on each iteration
         }
}
----


 dmd test.c -preview=dip1000


test.d(13): Error: reference to local variable `b` assigned to non-scope 
parameter `_param_0`

Looks like we can close it now!



 Note the first one is from 2008
 
 I think i can stop here because the point is made. All of these have long 
 standing bug report for them. Many of these reports are 10+ years old. Several 
 have DIPs.
 
 The problem here isn't that people aren't reporting these, or aren't writing
DIP 
 or whatever. It is that they are told to do so, waste their time doing that
and 
 then they get named argument instead.


BTW, the last comment in the bugzilla is from 2018. It hasn't been completely 
ignored all this time. It also happened to get fixed at some point.
May 23 2022
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.05.22 07:31, Walter Bright wrote:

 

 https://issues.dlang.org/show_bug.cgi?id=2043


 
 We have better tools to deal with 2043 today. Note that dgList exceeds 
 the lifetime of b, and should fail to compile for that reason.
 
 Let's try it (adding import and  safe and updating the code to D2):
 ----
 import std.stdio;
 
  safe:
 
 void delegate()[] dgList;
 
 void test() {
 
          foreach(int i; [1, 2, 3]) {
                  int b = 2;
                  dgList ~= { writeln(b); };
                  writeln(&b); // b will be the *same* on each
iteration
          }
 }
 ----
 
  > dmd test.c -preview=dip1000
 test.d(13): Error: reference to local variable `b` assigned to non-scope 
 parameter `_param_0`
 
 Looks like we can close it now!


No. The correct behavior when a delegate literal outlives captured 
variables is to allocate a closure. This case is not an exception...
May 24 2022
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 07:45:38 UTC, Timon Gehr wrote:

 On 24.05.22 07:31, Walter Bright wrote:

 

 https://issues.dlang.org/show_bug.cgi?id=2043


 
 We have better tools to deal with 2043 today. Note that dgList 
 exceeds the lifetime of b, and should fail to compile for that 
 reason.
 
 Let's try it (adding import and  safe and updating the code to 
 D2):
 ----
 import std.stdio;
 
  safe:
 
 void delegate()[] dgList;
 
 void test() {
 
          foreach(int i; [1, 2, 3]) {
                  int b = 2;
                  dgList ~= { writeln(b); };
                  writeln(&b); // b will be the *same* on each 
 iteration
          }
 }
 ----
 
  > dmd test.c -preview=dip1000
 test.d(13): Error: reference to local variable `b` assigned to 
 non-scope parameter `_param_0`
 
 Looks like we can close it now!


 No. The correct behavior when a delegate literal outlives 
 captured variables is to allocate a closure. This case is not 
 an exception...


This is a bit of a controversial topic. Personally I agree that 
there should be a closure allocated every loop pass, but *every 
other language* allocates them for the whole stackframe, so... 
But then handling b is awkward, because the way that compilers 
usually square that circle is that they allocate a separate spot 
in the stackframe *per variable declaration*, so the loop 
variable only gets one distinct declaration. And it's hard 
otherwise, because if you allocate a separate frame every loop, 
then they can't reference each others' variables. Some languages 
solve this by making lambdas unable to write scope variables, but 
then obviously they're less useful. Anyway, so in this case the 
delegate can't help outlive b *even if* it's closure allocated.
May 24 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 07:58:13 UTC, FeepingCreature wrote:

 This is a bit of a controversial topic. Personally I agree that 
 there should be a closure allocated every loop pass, but *every 
 other language* allocates them for the whole stackframe, so...




It is true of some languages, such as python, but this is because 
in python, variable scope is always the top level in the function.
May 24 2022
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 May 2022 at 13:34:07 UTC, deadalnix wrote:

 On Tuesday, 24 May 2022 at 07:58:13 UTC, FeepingCreature wrote:

 This is a bit of a controversial topic. Personally I agree 
 that there should be a closure allocated every loop pass, but 
 *every other language* allocates them for the whole 
 stackframe, so...






Unity, ~6 years ago. I work around it this way (pseudocode, 
didn't test this):

```D
foreach (i; 0..10)
{ auto makeDelegate(size_t closureVar)
   { return ()
     { // closureVar is i, but will be different for each iteration
     };
   };

   doSomethingWithDelegate(makeDelegate(i));
}
```
May 24 2022
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 13:49:28 UTC, Dukc wrote:

 On Tuesday, 24 May 2022 at 13:34:07 UTC, deadalnix wrote:

 On Tuesday, 24 May 2022 at 07:58:13 UTC, FeepingCreature wrote:

 This is a bit of a controversial topic. Personally I agree 
 that there should be a closure allocated every loop pass, but 
 *every other language* allocates them for the whole 
 stackframe, so...






 Unity, ~6 years ago. I work around it this way (pseudocode, 
 didn't test this):

 ```D
 foreach (i; 0..10)
 { auto makeDelegate(size_t closureVar)
   { return ()
     { // closureVar is i, but will be different for each 
 iteration
     };
   };

   doSomethingWithDelegate(makeDelegate(i));
 }
 ```
May 24 2022
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 13:34:07 UTC, deadalnix wrote:

 On Tuesday, 24 May 2022 at 07:58:13 UTC, FeepingCreature wrote:

 This is a bit of a controversial topic. Personally I agree 
 that there should be a closure allocated every loop pass, but 
 *every other language* allocates them for the whole 
 stackframe, so...




 It is true of some languages, such as python, but this is 
 because in python, variable scope is always the top level in 
 the function.


Javascript, yes:

```
function foo() {
     var cb = null;
     for (var i = 0; i < 10; i++) {
         if (!cb) {
             cb = function() { console.log("Hello World " + i); };
             cb();
         }
     }
     cb();
}
foo();
```
Hello World 0
Hello World 10
May 24 2022
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 15:15:13 UTC, FeepingCreature wrote:

 Javascript, yes:

 ```
 function foo() {
     var cb = null;
     for (var i = 0; i < 10; i++) {
         if (!cb) {
             cb = function() { console.log("Hello World " + i); 
 };
             cb();
         }
     }
     cb();
 }
 foo();
 ```
 Hello World 0
 Hello World 10


Now try this and tell me how it goes:

```
function foo() {
     var cb = null;
     for (var i = 0; i < 10; i++) {
         let n = i;
         if (!cb) {
             cb = function() { console.log("Hello World " + n); };
             cb();
         }
     }
     cb();
}
foo();
```

If you are capturing i and mutating it, then i is going to be 
mutated at the end. It says nothing about captures.
May 24 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 May 2022 at 15:15:13 UTC, FeepingCreature wrote:

 Javascript, yes:


If you use `var`, the variable is hoisted to the top-level scope 
of the function, so this behavior is then expected.

Use the `let` keyword for a local lexically scope thing, and then 
you'll see the cb behavior is different.

Since D's scoping is more like `let` than `var`, JS is a point in 
favor of it being a bug.

(though JS's pattern to make it work anyway is what I also do in 
D today. It isn't that big of a deal.... though the fact the 
`immutable` is a lie there is what convinces me it is a bug 
anyway.)
May 24 2022
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 15:31:47 UTC, Adam D Ruppe wrote:

 On Tuesday, 24 May 2022 at 15:15:13 UTC, FeepingCreature wrote:

 Javascript, yes:


 If you use `var`, the variable is hoisted to the top-level 
 scope of the function, so this behavior is then expected.

 Use the `let` keyword for a local lexically scope thing, and 
 then you'll see the cb behavior is different.


While this is true, his example is even worse: the captured 
variable isn't declared **IN** the loop, so whether `var` or 
`let` is used changes nothing.
May 24 2022
prev sibling next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 15:31:47 UTC, Adam D Ruppe wrote:

 On Tuesday, 24 May 2022 at 15:15:13 UTC, FeepingCreature wrote:

 Javascript, yes:


 If you use `var`, the variable is hoisted to the top-level 
 scope of the function, so this behavior is then expected.

 Use the `let` keyword for a local lexically scope thing, and 
 then you'll see the cb behavior is different.


Oh, I see!
May 24 2022
prev sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 24 May 2022 at 15:31:47 UTC, Adam D Ruppe wrote:

 Use the `let` keyword for a local lexically scope thing, and 
 then you'll see the cb behavior is different.

 Since D's scoping is more like `let` than `var`, JS is a point 
 in favor of it being a bug.


Also you should never use var anymore anyway, always use let if 
you can, which you can in 99.9% of all cases since it really only 
isn't supported with older engines.

In fact I'd argue that the only reason var isn't a deprecation in 
JS is because of legacy code.
May 24 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 6:34 AM, deadalnix wrote:

 but this is because in python, 
 variable scope is always the top level in the function.


Cheaters.

Scoped variables are a good thing.
May 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 12:45 AM, Timon Gehr wrote:

 No. The correct behavior when a delegate literal outlives captured variables
is 
 to allocate a closure. This case is not an exception...


But it isn't a safety problem, as it won't compile.
May 24 2022
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.05.22 19:10, Walter Bright wrote:

 On 5/24/2022 12:45 AM, Timon Gehr wrote:

 No. The correct behavior when a delegate literal outlives captured 
 variables is to allocate a closure. This case is not an exception...


 
 But it isn't a safety problem, as it won't compile.


Well, it's still a memory safety problem in  system code, it's just that 
it's not a soundness issue for  safe.
May 24 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 00:55, Timon Gehr wrote:

 On 24.05.22 19:10, Walter Bright wrote:

 On 5/24/2022 12:45 AM, Timon Gehr wrote:

 No. The correct behavior when a delegate literal outlives captured 
 variables is to allocate a closure. This case is not an exception...


 But it isn't a safety problem, as it won't compile.


 
 Well, it's still a memory safety problem in  system code, it's just that 
 it's not a soundness issue for  safe.


Actually, that's not even true. The line that does not compile does not 
even have to do anything with the issue. This compiles even with -dip1000:

```d
import std.stdio;

void main() safe{
     void delegate() safe[] dgList;
     foreach(i; [1, 2, 3]) {
         immutable b = i;
         dgList ~= { writeln(b); };
     }
     foreach(dg; dgList) dg();
}
```

I.e., this issue is alive and well. It's a memory safety issue in 
 system code and it's a soundness problem for  safe.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 4:35 PM, Timon Gehr wrote:

 This compiles even with -dip1000:
 
 ```d
 import std.stdio;
 
 void main() safe{
      void delegate() safe[] dgList;
      foreach(i; [1, 2, 3]) {
          immutable b = i;
          dgList ~= { writeln(b); };
      }
      foreach(dg; dgList) dg();
 }
 ```
 
 I.e., this issue is alive and well. It's a memory safety issue in  system code 
 and it's a soundness problem for  safe.


https://issues.dlang.org/show_bug.cgi?id=23136
May 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 3:55 PM, Timon Gehr wrote:

 On 24.05.22 19:10, Walter Bright wrote:

 On 5/24/2022 12:45 AM, Timon Gehr wrote:

 No. The correct behavior when a delegate literal outlives captured variables 
 is to allocate a closure. This case is not an exception...


 But it isn't a safety problem, as it won't compile.


 
 Well, it's still a memory safety problem in  system code, it's just that it's 
 not a soundness issue for  safe.


The whole point of  system is to remove the safety checks.

I'm more interested in soundness than in replicating closure semantics of other 
languages. Especially since the workarounds are simple:

Replace `int x` with `int* px = new int()`

I.e. one can always make a closure manually. It's not the end of the world if 
the compiler doesn't provide a spoonful of sugar for it.

Don't get me wrong, I'm still interested in adopting good semantics from other 
languages, it's just that soundness is much more of a priority.

I do enjoy and appreciate your contributions, too, even if it seems like I'm 
always arguing with you :-/
May 24 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 01:47, Walter Bright wrote:

 On 5/24/2022 3:55 PM, Timon Gehr wrote:

 On 24.05.22 19:10, Walter Bright wrote:

 On 5/24/2022 12:45 AM, Timon Gehr wrote:

 No. The correct behavior when a delegate literal outlives captured 
 variables is to allocate a closure. This case is not an exception...


 But it isn't a safety problem, as it won't compile.


 Well, it's still a memory safety problem in  system code, it's just 
 that it's not a soundness issue for  safe.


 ...


Sorry for the confusion, I had accepted your claim without examining 
your code example in detail as I was in a hurry this morning. You were 
just mistaken.


 The whole point of  system is to remove the safety checks.
 ...


 system still checks types, it just allows you to do some explicitly 
unsafe things such as type casts.


 I'm more interested in soundness


There is no soundness. Not in  system code. Not in  safe code.


 than in replicating closure semantics of other languages.
 Especially since the workarounds are simple:
 
 Replace `int x` with `int* px = new int()`
 ...


Well, I don't think it's exactly this simple as that pointer will be 
captured by reference.


 I.e. one can always make a closure manually. It's not the end of the 
 world if the compiler doesn't provide a spoonful of sugar for it.
 
 Don't get me wrong, I'm still interested in adopting good semantics from 
 other languages, it's just that soundness is much more of a priority.
 ...


Ok!


 I do enjoy and appreciate your contributions, too, even if it seems like 
 I'm always arguing with you :-/


Well, it's not my preference either, but I am fine with arguing if it's 
productive.

I have burned out a couple of times from engaging on the newsgroup 
though, because nothing got through to you. In this instance the problem 
seems to be that you are biased towards accepting immediately that stuff 
is actually not broken without examining closely enough what is going on.

Unfortunately, in such cases, arguing is taking away time and energy 
from both of us that could be spent trying to tackle those issues in a 
constructive way.
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 5:03 PM, Timon Gehr wrote:

 In this instance the problem seems to be 
 that you are biased towards accepting immediately that stuff is actually not 
 broken without examining closely enough what is going on.


I do what I can, but I expect things from users too:

    ** A bug report with a minimized example that illustrates the bug **

If the example does not illustrate a problem, then I move on to the next bug 
report. I've spent much time in the past trying to guess what the user meant, 
and usually guess wrong, which wastes everyone's time.

I can't get to all of them, so I prioritize the bugs where the submitter made
an 
effort to make it easier for me to deal with it.
May 24 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/05/2022 1:05 PM, Walter Bright wrote:

     ** A bug report with a minimized example that illustrates the bug **


dustmite <3

I ran into a bug related to extern(C++) classes in -betterC, already 
reported, did the minify.

Looks like the fix didn't make it into 2.100 sadly.

https://issues.dlang.org/show_bug.cgi?id=21416

I just want to say that the process certainly works when people like 
Razvan are around and able to fix these issues, rather than having to 
debate or argue about if it should be fixed or not.

It is appreciated!
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
We're indeed lucky to have Razvan on board!
May 24 2022
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 03:05, Walter Bright wrote:

 
 I do what I can, but I expect things from users too:
 
     ** A bug report with a minimized example that illustrates the bug **


Sure, that's fair.
May 24 2022
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 01:47, Walter Bright wrote:

 
 I do enjoy and appreciate your contributions, too, even if it seems like 
 I'm always arguing with you :-/


I guess this is as good an opportunity as any to also say that I highly 
appreciate the huge amount of work that you have invested into D. 
There's a lot that already works great.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 5:18 PM, Timon Gehr wrote:

 On 25.05.22 01:47, Walter Bright wrote:

 I do enjoy and appreciate your contributions, too, even if it seems like I'm 
 always arguing with you :-/


 
 I guess this is as good an opportunity as any to also say that I highly 
 appreciate the huge amount of work that you have invested into D. There's a
lot 
 that already works great.


Thanks, I like hearing that!
May 25 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 6:31 AM, deadalnix wrote:

 https://issues.dlang.org/show_bug.cgi?id=1983


It's been fixed already. Just nobody closed it.
May 23 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.05.22 07:39, Walter Bright wrote:

 On 5/22/2022 6:31 AM, deadalnix wrote:

 https://issues.dlang.org/show_bug.cgi?id=1983


 
 It's been fixed already. Just nobody closed it.


The original example no longer compiles, there are others in that 
thread. It has not been fixed!
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 12:43 AM, Timon Gehr wrote:

 The original example no longer compiles, there are others in that thread. It
has 
 not been fixed!


Other issues should get their own bugzilla issue.
May 24 2022
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.05.22 18:20, Walter Bright wrote:

 On 5/24/2022 12:43 AM, Timon Gehr wrote:

 The original example no longer compiles, there are others in that 
 thread. It has not been fixed!


 
 Other issues should get their own bugzilla issue.


You are twisting my words. It's not another issue, it's another 
_example_. It's just that the pull request only fixed some special case.

But sure, not really worth arguing. Whether or not the 15 year old 
bugzilla issue remains open or is replaced by a new duplicate report 
does not change much.
May 24 2022
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 May 2022 at 22:45:50 UTC, Timon Gehr wrote:

 But sure, not really worth arguing. Whether or not the 15 year 
 old bugzilla issue remains open or is replaced by a new 
 duplicate report does not change much.


We should probably re-open all the other issues that were marked 
duplicates of this one then, since there's plenty of other 
examples in there that do still compile without modifications.

And I'd point out the original example fails to compile for the 
wrong reason. So it isn't like it is actually fixed at all.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 4:28 PM, Adam Ruppe wrote:

 We should probably re-open all the other issues that were marked duplicates of 
 this one then, since there's plenty of other examples in there that do still 
 compile without modifications.
 
 And I'd point out the original example fails to compile for the wrong reason.
So 
 it isn't like it is actually fixed at all.


Timon created a clear example that compiles for the wrong reason:

https://issues.dlang.org/show_bug.cgi?id=23136
May 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 3:45 PM, Timon Gehr wrote:

 On 24.05.22 18:20, Walter Bright wrote:

 On 5/24/2022 12:43 AM, Timon Gehr wrote:

 The original example no longer compiles, there are others in that thread. It 
 has not been fixed!


 Other issues should get their own bugzilla issue.


 
 You are twisting my words. It's not another issue, it's another _example_.
It's 
 just that the pull request only fixed some special case.
 
 But sure, not really worth arguing. Whether or not the 15 year old bugzilla 
 issue remains open or is replaced by a new duplicate report does not change
much.


If the fix did not fix other cases, then they are separate bugs. They certainly 
may be related, but if they require more code, they are separate.

Our whole use of github and bugzilla revolves around a 1:1 correspondence 
between bug fixes and PRs. A 1:many and many:1 is just not manageable.
May 24 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 01:31, Walter Bright wrote:

 On 5/24/2022 3:45 PM, Timon Gehr wrote:

 On 24.05.22 18:20, Walter Bright wrote:

 On 5/24/2022 12:43 AM, Timon Gehr wrote:

 The original example no longer compiles, there are others in that 
 thread. It has not been fixed!


 Other issues should get their own bugzilla issue.


 You are twisting my words. It's not another issue, it's another 
 _example_. It's just that the pull request only fixed some special case.

 But sure, not really worth arguing. Whether or not the 15 year old 
 bugzilla issue remains open or is replaced by a new duplicate report 
 does not change much.


 
 If the fix did not fix other cases, then they are separate bugs. They 
 certainly may be related, but if they require more code, they are separate.
 


I don't buy that.


 Our whole use of github and bugzilla revolves around a 1:1 
 correspondence between bug fixes and PRs. A 1:many and many:1 is just 
 not manageable.
 


The issue is: sometimes there are pull requests that _don't actually fix 
the issue they purport to fix_. Why should that cause a changelog entry 
that claims the bug was fixed?
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 4:47 PM, Timon Gehr wrote:

 The issue is: sometimes there are pull requests that _don't actually fix the 
 issue they purport to fix_. Why should that cause a changelog entry that
claims 
 the bug was fixed?


If the supplied example works correctly, the bug is closed.

Is it really too much to ask for:

1. people to submit bug reports to bugzilla, not the n.g.?

2. provide an example of the bug?

Making me debug the provided example and/or guess what the submitter actually 
intended is too much to ask. (Often the subject line is completely wrong, too, 
and I often fix them.)

I've been cutting and pasting your n.g. bug reports to bugzilla. This really 
does not scale.
May 24 2022
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 02:23, Walter Bright wrote:

 On 5/24/2022 4:47 PM, Timon Gehr wrote:

 The issue is: sometimes there are pull requests that _don't actually 
 fix the issue they purport to fix_. Why should that cause a changelog 
 entry that claims the bug was fixed?


 
 If the supplied example works correctly, the bug is closed.
 ...


That encourages pseudo-fixes that focus on special cases.


 Is it really too much to ask for:
 
 1. people to submit bug reports to bugzilla, not the n.g.?
 ...


I do submit bug reports to bugzilla.


 2. provide an example of the bug?
 ...


Well, sometimes the person who finds the bug is not great at making 
examples, then others provide better ones on the same bug report.


 Making me debug the provided example and/or guess what the submitter 
 actually intended is too much to ask. (Often the subject line is 
 completely wrong, too, and I often fix them.)
 
 I've been cutting and pasting your n.g. bug reports to bugzilla. This 
 really does not scale.


All of the bug reports were already in bugzilla, though maybe my 
examples on the NG made the issues easier to understand.

I can get more proactive in filing enhancement requests again.
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 5:34 PM, Timon Gehr wrote:

 That encourages pseudo-fixes that focus on special cases.


Since I'm the one fixing the bugs, why would I be motivated to write
pseudo-fixes?

But if I do, then file a new bugzilla with an example that actually illustrates 
the problem. It's not like we're going to run out of bugzilla numbers.

I also dislike reopening closed bugzillas by adding more problems to it. Just 
open a new one.


 I do submit bug reports to bugzilla.


Good!


 Well, sometimes the person who finds the bug is not great at making examples, 


then others provide better ones on the same bug report.

If it's a mess, close it and open a new one that is better.


 All of the bug reports were already in bugzilla


Good, but how would I know without links posted?


 I can get more proactive in filing enhancement requests again.


Good!
May 25 2022
parent John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 25 May 2022 at 22:30:27 UTC, Walter Bright wrote:

 But if I do, then file a new bugzilla with an example that 
 actually illustrates the problem. It's not like we're going to 
 run out of bugzilla numbers.

 I also dislike reopening closed bugzillas by adding more 
 problems to it. Just open a new one.


 Well, sometimes the person who finds the bug is not great at


 making examples, then others provide better ones on the same 
 bug report.

 If it's a mess, close it and open a new one that is better.


If this is the chosen way to use bugzilla, there should be some 
way for people to know that, otherwise they will never do it.
May 28 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 23:31:58 UTC, Walter Bright wrote:

 If the fix did not fix other cases, then they are separate 
 bugs. They certainly may be related, but if they require more 
 code, they are separate.

 Our whole use of github and bugzilla revolves around a 1:1 
 correspondence between bug fixes and PRs. A 1:many and many:1 
 is just not manageable.


But they are not, and this is why this doesn't get resolve. These 
aren't bugs, there is a design issue.

You have essentially two way to go at it:
1/ Allocate a closure int he loop. This remains unsound by itself 
because the qualifier of the closure is not tracked, which lead 
to possible implicit sharing for instance and other nastyness. 
There is not enough information in the typesystem to solve this, 
so going at it bug by bug will simply be an exercise in wack a 
mole.
2/ Prevent capture of object beyond their lifetime. This require 
ownership and lifetime tracking. DIP1000 doesn't have the depth 
required to do so adequately - it lacks the recursiveness 
required to track indirections - so once again, fixing bugs one 
by one is an exercice in wack-a-mole.

Because the design is inadequate to begin with, you can only fix 
presumably more common holes (because they got reported first) by 
creating more uncommon ones at best, make no progress at worse.

To fix these problems, you actually need to think of the system 
it term of the invariant that each part either require or imply, 
and find where these do not match.

these problem with closure are quite complex, but there is an 
exemple of this that is much simpler and easy to grok: final 
switch vs non promoting binary operation on enums.

One assumes the invariant that enum are bounded to the set of 
values declared in the enum, but the second doesn't effectively 
relegating the enums to be a subtype of their base class. They 
just cannot be both within a sound system.

There is no amount of getting test cases to pass that will fix 
this problem with enums, because it is a design problems. Almost 
all soundness problems are, BTW.
May 24 2022
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 25.05.22 02:08, deadalnix wrote:

 
 1/ Allocate a closure int he loop. This remains unsound by itself 
 because the qualifier of the closure is not tracked, which lead to 
 possible implicit sharing for instance and other nastyness. There is not 
 enough information in the typesystem to solve this, so going at it bug 
 by bug will simply be an exercise in wack a mole.


Well, I would not call this specific case "whack-a-mole". Doing this is 
actually just a net positive as any unsoundness that remains is 
orthogonal to it and does not require a loop to trigger.

Anyway, the nice thing about closure context type checking in particular 
is that it's actually not so hard to get right, but it is certainly true 
that someone has to do a comprehensive implementation.
May 24 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 5:08 PM, deadalnix wrote:

 But they are not, and this is why this doesn't get resolve. These aren't bugs, 
 there is a design issue.


You've suggested I resolved the const conversion problem with some special case 
code. I did not. The other problem you said was the same is on a completely 
different path through the compiler. This needs to be a separate bug report.

I do try to resolve problems with a general solution. I never ever submit PRs
of 
the form:

     if (identifier == "a" && operator == "++") then insert hack.



 You have essentially two way to go at it:
 1/ Allocate a closure int he loop. This remains unsound by itself because the 
 qualifier of the closure is not tracked, which lead to possible implicit
sharing 
 for instance and other nastyness. There is not enough information in the 
 typesystem to solve this, so going at it bug by bug will simply be an exercise 
 in wack a mole.
 2/ Prevent capture of object beyond their lifetime. This require ownership and 
 lifetime tracking. DIP1000 doesn't have the depth required to do so adequately
- 
 it lacks the recursiveness required to track indirections - so once again, 
 fixing bugs one by one is an exercice in wack-a-mole.
 
 Because the design is inadequate to begin with, you can only fix presumably
more 
 common holes (because they got reported first) by creating more uncommon ones
at 
 best, make no progress at worse.
 
 To fix these problems, you actually need to think of the system it term of the 
 invariant that each part either require or imply, and find where these do not 
 match.


I'm sorry you've concluded I never think about these things. I am very well 
aware that dip1000 only looks one level. That's why I *also* implemented an 
ownership/borrowing system with  live. I know Timon does not like that
proposal, 
but that's another discussion entirely.

I have never introduced a PR to hack in a two-level indirection bug fix.



 these problem with closure are quite complex, but there is an exemple of this 
 that is much simpler and easy to grok: final switch vs non promoting binary 
 operation on enums.
 
 One assumes the invariant that enum are bounded to the set of values declared
in 
 the enum, but the second doesn't effectively relegating the enums to be a 
 subtype of their base class. They just cannot be both within a sound system.
 
 There is no amount of getting test cases to pass that will fix this problem
with 
 enums, because it is a design problems. Almost all soundness problems are, BTW.


You might be surprised to learn that I know that enums have no checks in them
to 
ensure an instance of an enum has only values matching the list of enum values. 
I haven't regarded it as terribly important because:

1. enums are often combined as bit flags
2. it's not a memory safety issue
3. it's the way C and C++ work and there is a user expectation for that behavior
May 24 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 05:39:50 UTC, Walter Bright wrote:

 On 5/22/2022 6:31 AM, deadalnix wrote:

 https://issues.dlang.org/show_bug.cgi?id=1983


 It's been fixed already. Just nobody closed it.


No.

```d
struct S {
     void delegate() dg;
}

void main() {
     int x = 42;
     immutable S s = { dg: () { x++; } };
     s.dg();

     import std.stdio;
     writeln(x);
}
```

This still compiles and run and mutates a variable through an 
immutable pointer. This variable could be shared too because 
immutable is safe to share.
May 24 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 6:13 AM, deadalnix wrote:

 On Tuesday, 24 May 2022 at 05:39:50 UTC, Walter Bright wrote:

 On 5/22/2022 6:31 AM, deadalnix wrote:

 https://issues.dlang.org/show_bug.cgi?id=1983


 It's been fixed already. Just nobody closed it.


 
 No.


Yes, the issue that opened the bugzilla is fixed.


 
 ```d
 struct S {
      void delegate() dg;
 }
 
 void main() {
      int x = 42;
      immutable S s = { dg: () { x++; } };
      s.dg();
 
      import std.stdio;
      writeln(x);
 }
 ```
 
 This still compiles and run and mutates a variable through an immutable
pointer. 
 This variable could be shared too because immutable is safe to share.


Other problems should get their own bugzilla. (Otherwise bugzilla becomes 
unmanageable.)
May 24 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 16:21:45 UTC, Walter Bright wrote:

 
 ```d
 struct S {
      void delegate() dg;
 }
 
 void main() {
      int x = 42;
      immutable S s = { dg: () { x++; } };
      s.dg();
 
      import std.stdio;
      writeln(x);
 }
 ```
 
 This still compiles and run and mutates a variable through an 
 immutable pointer. This variable could be shared too because 
 immutable is safe to share.


 Other problems should get their own bugzilla. (Otherwise 
 bugzilla becomes unmanageable.)


It is the same problem. There are example similar to this one in 
the issue. At some point, you'll have to decide if you want to 
fix these issues or if you want to massage things in a way a 
couple of test case passes, but which don't solve anything.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 9:40 AM, deadalnix wrote:

 It is the same problem. There are example similar to this one in the issue. At 
 some point, you'll have to decide if you want to fix these issues or if you
want 
 to massage things in a way a couple of test case passes, but which don't solve 
 anything.


Sometimes the same problem can exhibit very different symptoms and wind up with 
multiple distinct bug reports.

Sometimes problems that look similar have very different causes. I've often 
encountered the latter in one issue and wound up splitting them into multiple 
issues.

Which is which is unknowable without finding the source of each problem.

Since github works best with a 1:1 matching of bug report with fix, this is the 
most productive way to go about it.

Anyhow, this is not worth arguing about, so I created this:

https://issues.dlang.org/show_bug.cgi?id=23134
May 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2022 6:31 AM, deadalnix wrote:

 The problem here isn't that people aren't reporting these, or aren't writing
DIP 
 or whatever. It is that they are told to do so, waste their time doing that
and 
 then they get named argument instead.


I did a bugzilla search for every issue you have submitted:

https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&email1=deadalnix&emailreporter1=1&emailtype1=substring&list_id=240739&query_format=advanced&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=LATER&resolution=REMIND&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED

Every single one was resolved.

You are not wasting your time posting issues.

----------------------------


 I wrote DIP, they pretty much got ignored.


Here's a list of DIPs and their statuses:

https://github.com/dlang/DIPs/blob/master/DIPs/README.md

Which one is yours?
May 24 2022
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 20:36:52 UTC, Walter Bright wrote:

 On 5/22/2022 6:31 AM, deadalnix wrote:

 The problem here isn't that people aren't reporting these, or 
 aren't writing DIP or whatever. It is that they are told to do 
 so, waste their time doing that and then they get named 
 argument instead.


 I did a bugzilla search for every issue you have submitted:

 https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&email1=deadalnix&emailreporter1=1&emailtype1=substring&list_id=240739&query_format=advanced&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=LATER&resolution=REMIND&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED

 Every single one was resolved.

 You are not wasting your time posting issues.


When I report bug, they get fixed and it's great.

When I report design problem, they get treated as bugs and we 
never get to the root of the issue and I'm wasting my time.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 4:36 PM, deadalnix wrote:

 When I report bug, they get fixed and it's great.
 
 When I report design problem, they get treated as bugs and we never get to the 
 root of the issue and I'm wasting my time.



I'm sorry, there is nothing I can do with this as there's no link.

We *do* have a process for this:

1. bugs get reported on bugzilla
2. design bugs get reported on bugzilla as Enhancement Requests
3. significant design proposals get submitted as DIPs

What does not work and is not part of the process:

Reporting 1, 2 or 3 on the n.g. because then they scroll off the screen and 
vanish, as there is no organized way to deal with them.

For discussion of ideas, if you want them to go anywhere, submit them to 1, 2
or 
3. Then start a n.g. discussion, with a link to 1, 2 or 3.

People complain that the D Foundation does not have a process. It does. But it 
doesn't work if people ignore the process and just post things to the n.g. The 
forums are not a bug database.

It also doesn't work when people (not you) post bug reports to *closed* PR's! 
Nobody looks at closed PRs. That can't possibly work.

BTW, The C and C++ Standards committees will TOTALLY IGNORE any and all 
proposals that are not formal proposals submitted to the committee.
May 24 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 May 2022 at 20:36:52 UTC, Walter Bright wrote:

 I did a bugzilla search for every issue you have submitted:

 https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&email1=deadalnix&emailreporter1=1&emailtype1=substring&list_id=240739&query_format=advanced&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=LATER&resolution=REMIND&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED

 Every single one was resolved.

 You are not wasting your time posting issues.


Unfortunately, you have a bug in your search query. You should 
also include bugs that have no resolution.

Most of his bug reports are still fixed so you're right he hasn't 
been wasting time writing them, but it's not all of them.
May 25 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2022 4:55 AM, Dukc wrote:

 Unfortunately, you have a bug in your search query. You should also include
bugs 
 that have no resolution.


Why didn't you post the better link you used?
May 25 2022
parent reply mee6 <mee6 lookat.me> writes:
On Wednesday, 25 May 2022 at 21:54:02 UTC, Walter Bright wrote:

 On 5/25/2022 4:55 AM, Dukc wrote:

 Unfortunately, you have a bug in your search query. You should 
 also include bugs that have no resolution.


 Why didn't you post the better link you used?


Bugzilla is convoluted, what ever happened to switching to 
github? You wouldn't have this problem with github.
May 26 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 May 2022 at 12:24:34 UTC, mee6 wrote:

 Bugzilla is convoluted, what ever happened to switching to 
 github? You wouldn't have this problem with github.


It’s happening. Robert Schadek is expected to be ready with the 
migration script next month. He’s doing a related talk at DConf.

https://dconf.org/2022/
May 26 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Thursday, 26 May 2022 at 13:04:43 UTC, Mike Parker wrote:

 On Thursday, 26 May 2022 at 12:24:34 UTC, mee6 wrote:

 Bugzilla is convoluted, what ever happened to switching to 
 github? You wouldn't have this problem with github.


 It’s happening. Robert Schadek is expected to be ready with the 
 migration script next month. He’s doing a related talk at DConf.

 https://dconf.org/2022/


So... what happened to Vlad's bugzilla harmony proposal? It's 
decided that we're moving to GitHub issues?
May 26 2022
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 May 2022 at 13:22:34 UTC, Tejas wrote:


 So... what happened to Vlad's bugzilla harmony proposal? It's 
 decided that we're moving to GitHub issues?


https://forum.dlang.org/post/qrtjqubrbuqeiffunili forum.dlang.org


 Unfortunately, he reported that he has encountered a blocker. 
 He needs the configuration files for our active Bugzilla 
 instance, but the maintainer has so far been unresponsive. For 
 now, he will continue working on Bugzilla and will keep trying 
 to get the configuration files


AFAIK, he was never able to get the files he needed.
May 26 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 26 May 2022 at 12:24:34 UTC, mee6 wrote:

 Why didn't you post the better link you used?


 Bugzilla is convoluted, what ever happened to switching to 
 github? You wouldn't have this problem with github.


Not that I'm a big fan of bugzilla but how many user do you think 
really want to use D, but don't really want to do so because of 
bugzilla?

I estimate that number at exactly 0.

At least this won't break tooling, so it's still much better than 
random syntax changes, but nevertheless, the fact that no matter 
what discussion is started, it always revert back to this really 
is an example of the lack of focus that is holding D back.
May 26 2022
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 26 May 2022 at 13:48:43 UTC, deadalnix wrote:

 On Thursday, 26 May 2022 at 12:24:34 UTC, mee6 wrote:

 Why didn't you post the better link you used?


 Bugzilla is convoluted, what ever happened to switching to 
 github? You wouldn't have this problem with github.


 Not that I'm a big fan of bugzilla but how many user do you 
 think really want to use D, but don't really want to do so 
 because of bugzilla?

 I estimate that number at exactly 0.

 At least this won't break tooling, so it's still much better 
 than random syntax changes, but nevertheless, the fact that no 
 matter what discussion is started, it always revert back to 
 this really is an example of the lack of focus that is holding 
 D back.


I think almost all developers nowadays, except really few people 
who prefer other solution (gitlab, bitbucket, etc) or just denied 
to use it, have GitHub account.

More bugs reported -> more bugs fixed -> better D
May 26 2022
parent user1234 <user1234 12.de> writes:
On Thursday, 26 May 2022 at 15:05:15 UTC, Sergey wrote:

 On Thursday, 26 May 2022 at 13:48:43 UTC, deadalnix wrote:

 On Thursday, 26 May 2022 at 12:24:34 UTC, mee6 wrote:

 [...]


 Not that I'm a big fan of bugzilla but how many user do you 
 think really want to use D, but don't really want to do so 
 because of bugzilla?

 I estimate that number at exactly 0.

 At least this won't break tooling, so it's still much better 
 than random syntax changes, but nevertheless, the fact that no 
 matter what discussion is started, it always revert back to 
 this really is an example of the lack of focus that is holding 
 D back.


 I think almost all developers nowadays, except really few 
 people who prefer other solution (gitlab, bitbucket, etc) or 
 just denied to use it, have GitHub account.


Bugzilla does not force people to use 2FA.


 More bugs reported -> more bugs fixed -> better D


If bugs are not reviewed, sorted, checked then an issue tracker 
becomes a black hole no matter if it's bugzilla or GH.
May 27 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 26 May 2022 at 13:48:43 UTC, deadalnix wrote:

 the fact that no matter what discussion is started, it always 
 revert back to this really is an example of the lack of focus 
 that is holding D back.


If it were me, I would position D as `comfortable and safe` 
,`Fast should be the second goal`.

D's greatest advantage is `comfort`, which no one takes advantage 
of.

D should serve for `top programmers` and make them `comfortable`. 
This should be the goal of D!

The typical behave of `comfort` is `cool` just like your 
`configured ultimate` vim. `'comfort'` requires various switch 
configurations to meet your needs.

Yes, the slogan is `comfortable and safe`. `Come on ,Programmers`!
May 27 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 09:15:07 UTC, zjh wrote:


 Yes, the slogan is `comfortable and safe`. `Come on 
 ,Programmers`!


What `minority languages` need most is to attract `top 
programmers(core competitiveness)`. Otherwise, if no one writes 
the library for your, the ecology will hard to be `established`.
May 27 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 09:20:28 UTC, zjh wrote:

 On Friday, 27 May 2022 at 09:15:07 UTC, zjh wrote:


 Yes, the slogan is `comfortable and safe`. `Come on 
 ,Programmers`!





D lacks `top programmers`.
`D` should be `positioned` as serve for `top programmers`, and 
`library author` first!
And slogans should be `shouted out` loud on the "home page"! Just 
`fast` is not attractive.
May 27 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 May 2022 at 09:20:28 UTC, zjh wrote:

 What `minority languages` need most is to attract `top 
 programmers(core competitiveness)`. Otherwise, if no one writes 
 the library for your, the ecology will hard to be `established`.


Yes, so D could position itself as a higher level alternative to 
C, than C++, and focus on Linux applications.

But then we have to understand what those specific programmers 
are looking for and make the changes/improvements needed to grab 
that market.

Right now, D is too much of a personal expression to allow such 
market targetting to happen. But who knows?
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 09:29:46 UTC, Ola Fosheim Grøstad wrote:


 But then we have to understand what those specific programmers 
 are looking for and make the changes/improvements needed to 
 grab that market.


It is very important that ,the `D` offical should make an 
`investigation`. For example, why does`'d ` attract you? What are 
the '`defects`' of other `language`? How would you like `'d'` to 
serve you?

For me, some `metaprogramming functions` of c++ is not as cool as 
`d`.I hope that the `d` language can better link to my previous 
`C++ library`.
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 09:37:25 UTC, zjh wrote:
I hope that the `d` language can better link to my

 previous `C++ library`.


I also hope that d can have `...` operator.
It turns out that `'manu'` has a `'dip'`, which is obviously a 
good thing. Why not add it?
`D` need to learn `'c++''s success`.Add when you should.As long 
as `no use, no cost`. Then who cares.
As for `d's` becoming `complex` , which successful language is 
`not complex` in the end?
I just hope that I can configure like `'vim'`,`Everything is 
configurable`.
May 27 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 May 2022 at 10:07:53 UTC, zjh wrote:

 I also hope that d can have `...` operator.
 It turns out that `'manu'` has a `'dip'`, which is obviously a 
 good thing. Why not add it?


I dont understand why you want it. I think I have only used it 
once...

Rarely used features makes code difficult to read.


 As for `d's` becoming `complex` , which successful language is 
 `not complex` in the end?


I think languages get popular when they are simple enough, but 
not lacking. Then many languages keep adding stuff when they no 
longer grow, because they cater to people who already master it. 
As a result they become less accessible to beginners and maybe 
the next generation of programmers goes elseswhere.

It is important for small languages to avoid complexity and not 
overfocus on the demands of the hardcore users. Unlike big 
languages they totally depend on being accessible to beginners.
May 27 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 10:18:30 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 27 May 2022 at 10:07:53 UTC, zjh wrote:



 It is important for small languages to avoid complexity and not 
 overfocus on the demands of the hardcore users. Unlike big 
 languages they totally depend on being accessible to beginners.



`...` is very easy to use. I have it for almost `every function`. 
And there are all kinds of symbols,The technical term is `folding 
expression`.
`Hard` to read? No, it is very `cool`. You don't need 
`'for/foreach'` at all!
There are so many problems to be solved that `simplicity` must 
become `complicated`.

`C++` now has `corotine` and is more complicated, but who cares.
The important thing is to `'solve the problem'`, the important 
thing is `'cool'`!
May 27 2022
parent reply user1234 <user1234 12.de> writes:
On Friday, 27 May 2022 at 10:35:55 UTC, zjh wrote:

 On Friday, 27 May 2022 at 10:18:30 UTC, Ola Fosheim Grøstad 
 wrote:

 On Friday, 27 May 2022 at 10:07:53 UTC, zjh wrote:



 It is important for small languages to avoid complexity and 
 not overfocus on the demands of the hardcore users. Unlike big 
 languages they totally depend on being accessible to beginners.



 `...` is very easy to use. I have it for almost `every 
 function`. And there are all kinds of symbols,The technical 
 term is `folding expression`.


I think c++ needed this because it does not have a no-scope 
(static) foreach.
On the other side our unscoped foreach implementation is known to 
have limits.
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 10:51:58 UTC, user1234 wrote:


 I think c++ needed this because it does not have a no-scope 
 (static) foreach.
 On the other side our unscoped foreach implementation is known 
 to have limits.



This is not 'static foreach', it is folding expr. If you've 
written it, you know it's very cool.

```cpp
template<class...T>int f(char c,T&&...t){
     return b(c,t...)+c;
}
```
May 27 2022
parent reply user1234 <user1234 12.de> writes:
On Friday, 27 May 2022 at 11:00:20 UTC, zjh wrote:

 On Friday, 27 May 2022 at 10:51:58 UTC, user1234 wrote:


 I think c++ needed this because it does not have a no-scope 
 (static) foreach.
 On the other side our unscoped foreach implementation is known 
 to have limits.



 This is not 'static foreach', it is folding expr. If you've 
 written it, you know it's very cool.

 ```cpp
 template<class...T>int f(char c,T&&...t){
     return b(c,t...)+c;
 }
 ```


yes you're right when you suggest that I've never used it.

My point was actually more on the fact that "..." solves the fact 
that c++
foreach does not work on tuples, i.e aggregates made of different 
types, while D has static foreach, which can be similarly used 
let's say to unroll += on each member of a tuple.
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 14:46:47 UTC, user1234 wrote:

 while D has static foreach, which can be similarly used let's 
 say to unroll += on each member of a tuple.


I always say that `d` should learn `c++`.
`Add` as much as you need .
When `'c++'` users get used to `'c++'s ...` .`D ` should add it.
Don't be afraid of increasing `complexity`. Programming is a game 
of `intelligence`.
`D` should be configuriable like `'VIM'`. And give you what you 
like,everything is here for you to choose.

Your `target users` are mainly excellent `'c++' user groups`. As 
for `'rust'`, they are mainly atract people who can't learn 
`'c++'` well . Excellent `'c++'` users will not turn to `'rust'`.

If you satisfy `'c++'` users, they will come.
At least I have what `others` have.

And also `...` and arrays are `orthogonal`.
They are different concepts. `C++'s` folding expressions can 
match many `operators`.It's so convenient.
May 27 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 15:13:55 UTC, zjh wrote:


The `...` accompanying `sequence index` is very powerful!
`All sorts of strange skills` .
This is not a `simple tuple` or `static foreach` can match.It's 
too powerful.
May 27 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 27 May 2022 at 15:21:20 UTC, zjh wrote:

 On Friday, 27 May 2022 at 15:13:55 UTC, zjh wrote:


 The `...` accompanying `sequence index` is very powerful!
 `All sorts of strange skills` .
 This is not a `simple tuple` or `static foreach` can match.It's 
 too powerful.


The D equivalent of C++ `...` is [`staticMap`][1] from `std.meta`.

[1]: https://phobos.dpldocs.info/std.meta.staticMap.html
May 27 2022
next sibling parent reply mee6 <mee6 lookat.me> writes:
On Friday, 27 May 2022 at 16:30:33 UTC, Paul Backus wrote:

 On Friday, 27 May 2022 at 15:21:20 UTC, zjh wrote:

 On Friday, 27 May 2022 at 15:13:55 UTC, zjh wrote:


 The `...` accompanying `sequence index` is very powerful!
 `All sorts of strange skills` .
 This is not a `simple tuple` or `static foreach` can 
 match.It's too powerful.


 The D equivalent of C++ `...` is [`staticMap`][1] from 
 `std.meta`.

 [1]: https://phobos.dpldocs.info/std.meta.staticMap.html


You can do more than just map, you'd probably have to include 
more helper types to get the same behavior. Which should really 
be built into the language, which is what C++ did.
May 27 2022
parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 16:42:26 UTC, mee6 wrote:

 Which should really be built into the language, which is what 
 C++ did.


Right!
May 27 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 May 2022 at 16:30:33 UTC, Paul Backus wrote:

 On Friday, 27 May 2022 at 15:21:20 UTC, zjh wrote:

 On Friday, 27 May 2022 at 15:13:55 UTC, zjh wrote:


 The `...` accompanying `sequence index` is very powerful!
 `All sorts of strange skills` .
 This is not a `simple tuple` or `static foreach` can 
 match.It's too powerful.


 The D equivalent of C++ `...` is [`staticMap`][1] from 
 `std.meta`.


  Zjh is talking about builtin functional style fold expressions 
applied to parameter packs and std:: integer_sequence.

It can be very convenient for summing sizes etc, but I have found 
the use cases to be limited in real code.

maybe zjh could show some examples?
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 17:10:28 UTC, Ola Fosheim Grøstad wrote:


 maybe zjh could show some examples?



`...` with `concept` is the `most powerful thing` of `'c++'`!
May 27 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 28 May 2022 at 00:27:55 UTC, zjh wrote:

 On Friday, 27 May 2022 at 17:10:28 UTC, Ola Fosheim Grøstad 
 wrote:


 maybe zjh could show some examples?



 `...` with `concept` is the `most powerful thing` of `'c++'`!


Parameter packs is a last resort, so well written code will not 
use it all that often. If ... worked with all sequences then it 
would make more sense. C++ has too many special cases and D does 
not need more special cases either.

(Folding with subtraction is also problematic.)
May 27 2022
parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 05:59:05 UTC, Ola Fosheim Grøstad 
wrote:

  If ... worked with all sequences then it

 would make more sense.



No `...` for me is like dancing with handcuffs.
you don't understand the beauty of `(...) and (...,...) etc`.
May 27 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 28 May 2022 at 06:17:56 UTC, zjh wrote:

 No `...` for me is like dancing with handcuffs.


Never heard that expression, is it Chinese?


 you don't understand the beauty of `(...) and (...,...) etc`.


Ok, but I don’t think D will add folding over the comma-operator 
like C++. Also, you can implement you own fold in D.

Have you looked at Haskell? It has some of that beauty of dancing 
with handcuffs.
May 28 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 08:18:16 UTC, Ola Fosheim Grøstad 
wrote:

 like dancing with handcuffs.



It means `too much` trouble.
May 28 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 28 May 2022 at 09:18:02 UTC, zjh wrote:

 On Saturday, 28 May 2022 at 08:18:16 UTC, Ola Fosheim Grøstad 
 wrote:

 like dancing with handcuffs.


 It means `too much` trouble.


Ok, I misunderstood. I think proper tuples that can hold both 
types and values is the best approach, then add operators on 
tuples. C++ and D got it wrong by having some weird special cases 
for parameters, which is just annoying. Cannot be fixed for C++, 
but it is fixable for D.

Solid and generally useful tuples is the only basic feature D is 
missing (and move semantics, but not sure if that qualifies as 
basic).
May 28 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 28 May 2022 at 08:18:16 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 28 May 2022 at 06:17:56 UTC, zjh wrote:

 No `...` for me is like dancing with handcuffs.


 Never heard that expression, is it Chinese?


 you don't understand the beauty of `(...) and (...,...) etc`.


 Ok, but I don’t think D will add folding over the 
 comma-operator like C++. Also, you can implement you own fold 
 in D.

 Have you looked at Haskell? It has some of that beauty of 
 dancing with handcuffs.


Folding in C++ is a way to escape from the recursive template 
parameter parsing which is in my opinion one of the most horrific 
things in C++ there is.

Folding in C++ is perhaps "powerful" but at the same time 
unreadable.

D doesn't need folding and should use compile time for loops 
instead which is much more readable.
May 28 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 28 May 2022 at 17:32:04 UTC, IGotD- wrote:

 Folding in C++ is perhaps "powerful" but at the same time 
 unreadable.


I find it to be quite limited, but also confusing for the reader:

```
template<typename T, T... ints>
void f(std::integer_sequence<T, ints...> seq){
     std::cout << (ints - ...) << std::endl; // prints 3
     std::cout << (... - ints) << std::endl; // prints -5
     std::cout << (0 - ... - ints) << std::endl; // prints -7
     ((std::cout << ints), ...); // prints 124
}

int main()
{
     f(std::integer_sequence<int,1,2,4>{});
     return 0;
}

```
May 28 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 28 May 2022 at 18:15:10 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 28 May 2022 at 17:32:04 UTC, IGotD- wrote:

 Folding in C++ is perhaps "powerful" but at the same time 
 unreadable.


 I find it to be quite limited, but also confusing for the 
 reader:


Two nested folds (nested loops):


```
template<int... as, int... bs>
void f(std::integer_sequence<int, as...> 
_1,std::integer_sequence<int, bs...> _2) {

     std::cout << ([](auto x){ return ((bs+x) * ...);}(as) + ...) 
<< std::endl;

}


int main()
{
     f(std::integer_sequence<int,1,2,4>{}, 
std::integer_sequence<int,1,-1>{});
     return 0;
}
```

How many seconds do you need to understand what goes on?

(Maybe it would be better to just implement Lisp.)
May 28 2022
next sibling parent mw <mingwu gmail.com> writes:
On Saturday, 28 May 2022 at 19:30:42 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 28 May 2022 at 18:15:10 UTC, Ola Fosheim Grøstad 
 wrote:

 On Saturday, 28 May 2022 at 17:32:04 UTC, IGotD- wrote:

 Folding in C++ is perhaps "powerful" but at the same time 
 unreadable.


 I find it to be quite limited, but also confusing for the 
 reader:


 Two nested folds (nested loops):


 ```
 template<int... as, int... bs>
 void f(std::integer_sequence<int, as...> 
 _1,std::integer_sequence<int, bs...> _2) {

     std::cout << ([](auto x){ return ((bs+x) * ...);}(as) + 
 ...) << std::endl;

 }


 int main()
 {
     f(std::integer_sequence<int,1,2,4>{}, 
 std::integer_sequence<int,1,-1>{});
     return 0;
 }
 ```

 How many seconds do you need to understand what goes on?

 (Maybe it would be better to just implement Lisp.)



Wow, haven't looked at C++ for decades, it has advanced this far? 
Truely marvelous ;-) a vivid testimony of Greenspun's tenth rule:

Any sufficiently complicated C or Fortran program contains an ad 
hoc, informally-specified, bug-ridden, slow implementation of 
half of Common Lisp.


(just plug in C++ here :-)


https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
May 28 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 19:30:42 UTC, Ola Fosheim Grøstad 
wrote:

 


As long as the implementation is correct, I don't need to 
understand it. Just give a good function name. After the 
implementation, I don't care about the implementation.
May 28 2022
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 29 May 2022 at 00:50:45 UTC, zjh wrote:

 After the implementation, I don't care about the implementation.


`Iteration and expansion` are orthogonal in nature. They are two 
ways of thinking.
As a system language, `others` have it, but you don't. This is 
not a `complete/systematic` system language.
They look difficult. but smell good ,and when used to use 
them,they are cool!
May 28 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Sunday, 29 May 2022 at 00:56:26 UTC, zjh wrote:


 `Iteration and expansion` are orthogonal in nature. They are 
 two ways of thinking.



For simple iteration, one can use `...`.
It's easy. Not that hard.
May 28 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 29 May 2022 at 00:56:26 UTC, zjh wrote:

 As a system language, `others` have it, but you don't. This is 
 not a `complete/systematic` system language.
 They look difficult. but smell good ,and when used to use 
 them,they are cool!


It is not so much that they look difficult, if you are used to 
functional programming then it is passable, but most C++ 
programmers are not used to functional programming.

If you want to have it, then it should work with all sequences, 
because if you almost never use them then you will simply not 
remember what they do (which one is left fold, which one is right 
fold?)

Adding a single functional programming mechanism in a remote 
corner of the language is just a hack, not a real solution.
May 29 2022
parent zjh <fqbqrr 163.com> writes:
On Sunday, 29 May 2022 at 09:43:23 UTC, Ola Fosheim Grøstad wrote:

`And` this is not `'functional'` at all, it is just expand an 
`iteration`.
It's very `simple` .I don't like `functional programming` at all.
  But I like `...` very much, Because it avoids using 
`for/foreach` and frees the `productivity`!

I generally don't need to remember folding `left/right` at all. 
Besides, even if it's complicated, you can find everything by 
`just searching` on the web.
This is not `corner skill`, this is `productivity`!
May 29 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 16:30:33 UTC, Paul Backus wrote:


 The D equivalent of C++ `...` is [`staticMap`][1] from 
 `std.meta`.


and to `user1234`,like this etc:

```cpp
template<int K,int M,class F,int...J,class...T>
void gg(F&f,seq<J...>,T&...t){
     (hh(f,G<K,M,J>(),t...),...);
}
```
`...` means combat effectiveness and productivity.
May 27 2022
prev sibling parent reply user1234 <user1234 12.de> writes:
On Friday, 27 May 2022 at 15:13:55 UTC, zjh wrote:

 On Friday, 27 May 2022 at 14:46:47 UTC, user1234 wrote:

 while D has static foreach, which can be similarly used let's 
 say to unroll += on each member of a tuple.


 I always say that `d` should learn `c++`.
 `Add` as much as you need .
 When `'c++'` users get used to `'c++'s ...` .`D ` should add it.
 Don't be afraid of increasing `complexity`. Programming is a 
 game of `intelligence`.
 `D` should be configuriable like `'VIM'`. And give you what you 
 like,everything is here for you to choose.

 Your `target users` are mainly excellent `'c++' user groups`. 
 As for `'rust'`, they are mainly atract people who can't learn 
 `'c++'` well . Excellent `'c++'` users will not turn to 
 `'rust'`.

 If you satisfy `'c++'` users, they will come.
 At least I have what `others` have.

 And also `...` and arrays are `orthogonal`.
 They are different concepts. `C++'s` folding expressions can 
 match many `operators`.It's so convenient.


yes this is bit what I had in mind, that looks like a very 
specific unrolled operation that c++ can only handle with '...' 
So C++ can handle 32 operators with "..." but D has not limit, 
although the syntax is a bit less friendly.

For example what if the tuple contains a value whose type is not 
compatible with one of the 32 operators ? You see in D you can 
handle that in a static condition.
May 27 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 May 2022 at 16:15:53 UTC, user1234 wrote:

 that looks like a very specific unrolled operation that c++ can 
 only handle with '...'


It is just syntax sugar, you can handle it with recursion in C++ 
as well. There was no real need for it.
May 27 2022
parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 18:47:22 UTC, Ola Fosheim Grøstad wrote:


 It is just syntax sugar.


`Syntax sugar` is competitiveness.

  Do you want to go back to `c++98`?
I always use the `latest version` of `'c++'`,
It's too powerful.
May 27 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 10:18:30 UTC, Ola Fosheim Grøstad wrote:


 It is important for small languages to avoid complexity and not 
 overfocus on the demands of the hardcore users. Unlike big 
 languages they totally depend on being accessible to beginners.



If language wants to attract `top programmers`, it must meet the 
needs of them.

As long as the `feature` is satisfied, and there is `no cost` if 
it is `not used` .
No one 'cares' about `adding new features`.
The more `features`, the better, as long as they meet the needs 
of `top programmers`!
Why do beginners know so much,learning while using like `vim`.

The `library author` is the most `important`.
And `excellent programmers` are the `core competitiveness` for a 
`language`.
May 27 2022
parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 10:48:46 UTC, zjh wrote:


 The `library author` is the most `important`.
 And `excellent programmers` are the `core competitiveness` for 
 a `language`.


No one writes `library` for you. And you want to expand the 
`ecology`?

The `library author` is the most `important`.
And `excellent programmers` are the `core competitiveness` for a 
`language`.

Repeate 3 times!
May 27 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 27 May 2022 at 10:07:53 UTC, zjh wrote:

 On Friday, 27 May 2022 at 09:37:25 UTC, zjh wrote:
 I hope that the `d` language can better link to my

 previous `C++ library`.


 I also hope that d can have `...` operator.
 It turns out that `'manu'` has a `'dip'`, which is obviously a 
 good thing. Why not add it?
 `D` need to learn `'c++''s success`.Add when you should.As long 
 as `no use, no cost`. Then who cares.
 As for `d's` becoming `complex` , which successful language is 
 `not complex` in the end?
 I just hope that I can configure like `'vim'`,`Everything is 
 configurable`.


Stop adding new crap int he language, unless it fixes existing 
crap. Once the existing crap is in decent shape, we'll think 
about `...`. Endless pursuing the next shinny object- is how we 
got where we are.

Even in this thread, this keeps happening. It's like an addition.
May 27 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 21:17:04 UTC, deadalnix wrote:


 Stop adding new crap int he language, unless it fixes existing 
 crap. Once the existing crap is in decent shape, we'll think 
 about `...`. Endless pursuing the next shinny object- is how we 
 got where we are.


It's not `that serious`. The `core problem` is too difficult. You 
can solve the `easy ones` first.

Take your time with `important bugs`.
May 27 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/27/2022 2:17 PM, deadalnix wrote:

 On Friday, 27 May 2022 at 10:07:53 UTC, zjh wrote:

 I also hope that d can have `...` operator.
 It turns out that `'manu'` has a `'dip'`, which is obviously a good thing. Why 
 not add it?




Because it did not work in general. I don't recall the specifics, but it should 
be there in the discussion of it.
May 27 2022
parent zjh <fqbqrr 163.com> writes:
On Saturday, 28 May 2022 at 01:12:38 UTC, Walter Bright wrote:


 Because it did not work in general. I don't recall the 
 specifics, but it should be there in the discussion of it.



`C++'s` combination of `...` and `concept` and `index sequence` 
is very powerful .
I hope `d` can also have it. I hope  manu can continue that 
`dip`. I haven't seen him for a long time.
May 27 2022
prev sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 27 May 2022 at 09:15:07 UTC, zjh wrote:

 On Thursday, 26 May 2022 at 13:48:43 UTC, deadalnix wrote:

 the fact that no matter what discussion is started, it always 
 revert back to this really is an example of the lack of focus 
 that is holding D back.


 If it were me, I would position D as `comfortable and safe` 
 ,`Fast should be the second goal`.


If this is what you are looking for, then something like Python 
may be a perfect fit. And Python is indeed extremely popular. If 
you give up on 'fast', then this pits D language against many 
comfortable and safe programming languages.
May 27 2022
parent zjh <fqbqrr 163.com> writes:
On Friday, 27 May 2022 at 09:31:32 UTC, Siarhei Siamashka wrote:


 If this is what you are looking for, then something like Python 
 may be a perfect fit. And Python is indeed extremely popular.


Dynamic language is a `hole`. What I need is static language.
Wrong, I didn't `give up` fast. Just `comfort and safety` first!
In other words, I like writing code very `comfortable`.
Like `'c++'`, `every time` at the end, I have to use `macros`. 
That feeling, you know?

Why don't you like '`rust`'.
when you see the full screen `::`,do you have a good `impression`?
Therefore, I hope that `d's ecology` can grow up.
`D` need to know, who do you serve, Big company? No!
D should not serve for `big company`. On the contrary, d should 
serve for programmers and `top programmers` first, and make them 
`happy`. This is my view of `d's` reasonable positioning.
May 27 2022
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 20 May 2022 at 11:28:38 UTC, deadalnix wrote:

 So I was catching up with he humongous thread. What stroke me 
 in there is that almost everybody is missing the point, but 
 maybe that isn't so surprising, as there is a self selection 
 bias at play.

 I especially noticed this post: 
 https://forum.dlang.org/post/kkmlkebnsbembkispcya forum.dlang.org

 Apparently, we are getting named argument soon. I have no 
 opinion whether this is good or bad, I haven't even read he 
 proposal. But I don't need to to know this is pretty bad for D, 
 even if the proposal is really good.

 I'd like to remind everybody of a simple fact: it is impossible 
 to write a high quality generic container in D, right now. This 
 is because there is no way to explain to the compiler that a 
 `const Vector!T` is the same as a `const Vector!(const T)`.

 There is no syntactic sugar, no optimization, no static 
 analysis, no nothing that can compensate for this, just like it 
 doesn't matter how comfortable the seat are on a car which has 
 no wheels.

 On the other hand, this will yet again break many tools, 
 setting the ecosystem back once again. This same pattern has 
 been repeating for at least a decade by now.


this thread and the previous as well has a strong "conoisseur" 
bias.
You finally ends up with testimonials from experts but in the end 
you still dont really know why mr rookie gave D up.
May 23 2022
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 02:04:34 UTC, Basile B. wrote:

 this thread and the previous as well has a strong "conoisseur" 
 bias.
 You finally ends up with testimonials from experts but in the 
 end you still dont really know why mr rookie gave D up.


Obviously, the story is going to change from rookie to rookie, 
but generally, you got to really nail something. because then you 
get the people who have that very specific thing in need of 
nailing as avid follower, and you move on the next niche.

For instance, Rust really nailed the whole ownership thing. I 
remember 10 years ago Andrei pointing out that Rust skipped leg 
day. he was right: D was better than Rust at everything but one 
thing: ownership. Now Rust is better at many things.

Rust's story isn't unique, it is actually very common.

D main's problem is that it is good at many things, probably more 
things than most, but it doesn't really nails anything.
May 23 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 02:04:34 UTC, Basile B. wrote:

 You finally ends up with testimonials from experts but in the 
 end you still dont really know why mr rookie gave D up.


Overall the signal from beginners that did not give up early 
appears to be IDE and libraries. From experienced beginners the 
signal is inconsistencies and unusual choices. From nonhardcore 
the signal is lack of stability. From hardcore the signal is 
incompleteness.

Then the usual requests for features from other languages...

Adding more features is probably not an improvement overall.
May 23 2022
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 05:22:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 24 May 2022 at 02:04:34 UTC, Basile B. wrote:

 You finally ends up with testimonials from experts but in the 
 end you still dont really know why mr rookie gave D up.


 Overall the signal from beginners that did not give up early 
 appears to be IDE and libraries. From experienced beginners the 
 signal is inconsistencies and unusual choices. From nonhardcore 
 the signal is lack of stability. From hardcore the signal is 
 incompleteness.


Actually, I want to jump on this, because I think it's really 
important, and it's a core argument from my perspective for why D 
should have macros.

Note: Speaking from an unabashed late-intermediate perspective.

Most languages have this sort of pipeline:

[beginners] -> [experienced beginners] -> [intermediates] -> 
[hardcore]

[code for own use] -> [code libraries] -> [utility libraries] -> 
[language improvements]

It sometimes feels like D has this pipeline:

[code for own use] -> [libraries] -> [clever metaprogramming 
libraries] -> [I'll make my own language!]

And that's an issue! Because people tend to fall off the end of 
the development pipeline right when they're the most useful. 
There's what, five languages that started from D? Amber, Volt, 
Symmetry's fork (?), my own Neat... It's gotten less with D2, but 
I feel the combination of limitations at the high end of utility 
libraries and the lack of truly deep language expansion on the 
one hand, the slow, somewhat opaque, and arguably 
criticism-driven DIP process on the other, and the, charitably, 
somewhat impenetrable DMD codebase on the third, risks alienating 
people when they'd be the most useful to the project.

With something like C++ I ironically think that's less of an 
issue because there's "more to learn" at the high end. I think 
people rarely feel like they've plateaued in how far they can 
take the language, because they get so stuck in their awkward 
templates that even gradual improvements feel like victories. Or 
with simpler languages, like Node, it's easier to make a case 
that what's there is complete, from a language perspective. But 
because D is both powerful and comprehensible, you reach "the 
end", understand it, and you see that there's nowhere else to go 
except either braving the feature proposal process and the 
hostility of half the forum, or go elsewhere.

To be clear, losing people at any stage of the pipeline is bad 
for a language. But I think losing people at the end has unique 
costs in terms of proselytizing and advancement.
May 23 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 06:17:38 UTC, FeepingCreature wrote:

 Actually, I want to jump on this, because I think it's really 
 important, and it's a core argument from my perspective for why 
 D should have macros.


Are you talking of AST macros?

The reason I think D should do proper expansion of C macros is 
just that it makes it possible to view it as a high level 
alternative to C, so you get some kind of marketable focus into 
the project. But there are some randomish anti-C design aspects 
that works against it.


 And that's an issue! Because people tend to fall off the end of 
 the development pipeline


Yes, something like SDC is needed, but it is difficult to believe 
in when D keeps moving in an unpredictable manner. Does SDC need 
importC?


 There's what, five languages that started from D?


Probably more, private forks... but it is easy to predict that 
SDC will be forced in a similar direction by first going for a 
subset and take a different direction.


 With something like C++ I ironically think that's less of an 
 issue because there's "more to learn" at the high end.


C++ has more focus by not being suitable for higher level coding. 
Too many D users want only one language for everything and that 
leads to neverending feature creep instead of polishing a more 
narrow reportoire.
May 24 2022
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 07:15:15 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 24 May 2022 at 06:17:38 UTC, FeepingCreature wrote:

 Actually, I want to jump on this, because I think it's really 
 important, and it's a core argument from my perspective for 
 why D should have macros.


 Are you talking of AST macros?


Yeah, some combination of CTFE and DMDFE-as-a-library to allow 
CTFE functions to operate on (some abstraction over) code trees 
directly. The idea is that something like format strings could be 
offered as a library before it even entered the DIP process. That 
might also allow pulling a bunch of functionality out of the core 
language.
May 24 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 05:22:48 UTC, Ola Fosheim Grøstad 
wrote:

 Adding more features is probably not an improvement overall.


Indeed, the breakage is also estimated in a very bizarre way (at 
the end of the day, it's all about cost of the breakage vs 
benefit of the change).

The worse offender as far as I can tell is random feature added. 
They break all kind of tooling, every time.
May 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2022 6:21 AM, deadalnix wrote:

 The worse offender as far as I can tell is random feature added. They break
all 
 kind of tooling, every time.


Everybody asks for bug fixes only, and btw add feature X.
May 24 2022
prev sibling parent reply burjui <bytefu gmail.com> writes:
Why D is unpopular? Because people don't stay. As I can only 
truly speak for myself, here's the reason why I left:
https://issues.dlang.org/show_bug.cgi?id=2043

This bug is 14 years old already, and the memory-corrupting code 
still compiles, unless you enable DIP1000 (not a standard yet).

There are many more papercuts like that in D: incomplete and 
poorly designed features, bugs that don't get fixed, the overall 
lack of computer science backing, resulting in what I would call 
a complex graph of hacks rather an elegant language.

And one of the main problems, imho, is Walter himself. He's like 
a child that wants to play with his favourite toys, e.g. ImportC, 
but hates doing homework. That's why we have many shiny new 
features in D, but bugs can rot their way into DMD for decades. I 
get that behaviour, I was like that most of my life. Judging from 
my own experience, he may even have untreated ADHD. He's great at 
programming, but sucks at leadership. And D is no longer his own 
toy, it's a project with many people depending on it. Whatever 
the problem with Walter is, it's outright irresponsible to have 
him as a leader.

Also, D definitely need a whole lot more of:
1. Compiler experts, because the current pace of progress is so 
incredibly slow, that eventually even the most hardcore fans will 
lose temper, like I did, and leave the project. By progress I 
mean not only adding features but fixing bugs too.
2. Computer scientists. You know, type theory and all the related 
stuff is really important in designing a language. There is a 
whole spectrum of complexity and usability, from Forth and Lisp 
to C++ and D. Both ends of the spectrum suck. There has to be 
some middle ground, where you have a sufficiently powerful, yet 
relatively simple language (relative to C++). For that, you need 
science. Slapping a yet another feature on top with scotch tape 
is not going to work in the long run.
May 24 2022
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 10:22:31 UTC, burjui wrote:

 And one of the main problems, imho, is Walter himself. He's 
 like a child that wants to play with his favourite toys, e.g. 
 ImportC, but hates doing homework. That's why we have many 
 shiny new features in D, but bugs can rot their way into DMD 
 for decades. I get that behaviour, I was like that most of my 
 life. Judging from my own experience, he may even have 
 untreated ADHD. He's great at programming, but sucks at 
 leadership. And D is no longer his own toy, it's a project with 
 many people depending on it. Whatever the problem with Walter 
 is, it's outright irresponsible to have him as a leader.


I cannot put into words how much I disagree with this.

Rough consensus and running code! History is made by those who 
bother to show up. Patches welcome. The project is on Github, 
there is a very visible fork button on the top left. That's the 
same reason I violently disagree with the idea that D has too 
little "management." There's this idea that if we just have a 
really good idea, it will materialize developers out of nowhere 
through the sheer force of its majesty. This is not how things 
work, or have ever worked.

Walter works on DMD. This makes him part of an all-too-small 
circle of people who actually contribute to this project in any 
way whatsoever. All the disagreements I have with the project are 
the *other* way - I think it's *too cumbersome* to just jump in 
and contribute. I think we need a lot more people just jumping in 
and coding wildly ahead, and then sharing their results. An 
experimental branch? D3? Whatever must be changed to make that 
possible, I support it.

"More people need to" - Whenever you say that more people need 
to, you don't have a solution, you have a *wish.* Them needing to 
will not make people care, or exist. Want more features? Argue 
for whatever stands between *existing* people in the ecosystem 
and adding features. Want more bugfixes? Ask people why they 
don't fix bugs. Ask *yourself* why you don't fix bugs.

It is my belief that if Walter leaves D, it will die within a 
year or two. A project needs action. I think the codebase is in 
an awkwardly hard-to-maintain state for outsiders: who will fix 
it? Whether or not Walter does it, who else would?

One of the worst things a project can do is penalize 
contributions, whether through cumbersome processes, bad code, or 
excessive criticism. Opinions are plentiful; pull requests are 
scarce. It is always thus.
May 24 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

 I think we need a lot more people just jumping in and coding 
 wildly ahead, and then sharing their results. An experimental 
 branch? D3? Whatever must be changed to make that possible, I 
 support it.


You need a solid modular architecture to support evolutionary 
development. There is enough CPU power to take the overhead in 
2022. Designing architecture is hard on-paper work, not something 
you evolve though. So that is where one should start.

If you want merging to be easy then you need to select features 
that are independent in each iteration. People working on random 
things make the process harder and more brittle, but a solid 
architecture and AST macros can help. Depends, only one type 
system feature at a time for instance...

Maybe Neat and SDC could be joined and form a foundation?

Think O(N) and modularity and forget all other performance 
metrics until you hit v1.0... Designing for flexibility is quite 
challenging. GC is ok etc...
May 24 2022
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 24 May 2022 at 13:09:54 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

 I think we need a lot more people just jumping in and coding 
 wildly ahead, and then sharing their results. An experimental 
 branch? D3? Whatever must be changed to make that possible, I 
 support it.


 Maybe Neat and SDC could be joined and form a foundation?


(Brief sidenote: Neat is a totally different compiler and 
language, it only steals some syntax from D. It's a project that 
is motivated by my experience with D, but it's not a D variant. 
It's doing its own thing, language-wise. Not to mention that it's 
far pre-1.0 in terms of D-equivalent features.)


 You need a solid modular architecture to support evolutionary 
 development. There is enough CPU power to take the overhead in 
 2022. Designing architecture is hard on-paper work, not 
 something you evolve though. So that is where one should start.


Fully agreed, but don't underestimate how magical DMD's 
performance is. I wish neat's compiler was as speedy.
May 24 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 13:13:01 UTC, FeepingCreature wrote:

 Fully agreed, but don't underestimate how magical DMD's 
 performance is. I wish neat's compiler was as speedy.


Nowadays I find that IDE semantic analysis performance is most 
important. I am getting used to fixing bugs before compilation.

Designing the language so that static analysis can be cached 
might become the holy grail of development speed... tricky issue 
to think about though. Might limit lookup strategies...
May 24 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

 A project needs action.


It's actually very simple,Just `prioritize coding tasks`.
We should `organize` the community.
D community should be organized, even if it is loose, it is 
better than unorganized.
The problem with the `d` community is that it is `too loose`.
May 24 2022
parent reply zjh <fqbqrr 163.com> writes:
On Tuesday, 24 May 2022 at 13:21:53 UTC, zjh wrote:


 We should `organize` the community.
 D community should be organized,


what `D` need is  `organization`, and to `make effective use of 
`our spare time .
Moreover, `consensus` should be strengthened.
For the things that have been discussed, just give a link. You 
don't have to discuss the same things `repeatedly`. It's too 
annoying and `a waste of time`.
May 24 2022
parent zjh <fqbqrr 163.com> writes:
On Tuesday, 24 May 2022 at 13:30:15 UTC, zjh wrote:


 We should `organize` the community.




Since we all use `d` language, you have to `feedback and repair` 
it. If you don't make effort to it, you can only see `other 
languages` surpass you, and there's nothing you can do.
Since `we all` use d language, `we` are all on `the same boat`.
If `D language` is not good, everyone has to suffer.
Therefore, the `'d'` language community should not be too 
`loose`, but should be `organized`.
Everyone can partially uses their `spare time` to serve for 
`'d'`.Of course,`'D'` officials can pay according to their 
ability.
Without money, you can give honor, right?

`D` man should `organize`, otherwise D `users` are `losers`.
May 24 2022
prev sibling next sibling parent mee6 <mee6 lookat.me> writes:
On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

 Ask people why they don't fix bugs. Ask *yourself* why you 
 don't fix bugs.


I don't get paid to. It's also an awful developer experience. 
There's no readme that explains how to build it, it's better now 
with the build.d script but until recently you just had to wing 
it. Still do for phobos and druntime. Also a lot of the time pull 
requests just stay open, for various reasons including requesting 
Walters approval which he'll never look at.

It takes a lot of time to get up to speed to fix bugs in DMD. I 
don't know if the people in the d foundation are getting paid but 
I assume they are. If you want more people in the community to 
fix bugs, you have.to pay them. It takes skill to do that. 
Otherwise people want to work on their own projects and not spend 
hours fixing a bug they hit in a tool they are using for their 
project, then to only have your pull request closed cause it got 
stale waiting for someone to look at it.
May 24 2022
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

 One of the worst things a project can do is penalize 
 contributions, whether through cumbersome processes, bad code, 
 or excessive criticism. Opinions are plentiful; pull requests 
 are scarce. It is always thus.


The only thing clear from those length "D needs X" threads is 
that the D forums needs more moderation and banning abusive 
language and behaviour. Unless we want more of that?
May 24 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
There is also research about language adoption, and quoting 
https://dl.acm.org/doi/10.1145/2509136.2509515


  Second, intrinsic features have only secondary importance in 
 adoption. **Open source libraries, existing code, and 
 experience strongly influence developers when selecting a 
 language for a project. Language features such as performance, 
 reliability, and simple semantics do not.** Third, developers 
 will steadily learn and forget languages. The overall number of 
 languages developers are familiar with is independent of age. 
 Finally, when considering intrinsic aspects of languages, 
 developers prioritize expressivity over correctness.
May 24 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 20:27:47 UTC, Guillaume Piolat wrote:

 There is also research about language adoption, and quoting 
 https://dl.acm.org/doi/10.1145/2509136.2509515


  Second, intrinsic features have only secondary importance in 
 adoption. **Open source libraries, existing code, and 
 experience strongly influence developers when selecting a 
 language for a project. Language features such as performance, 
 reliability, and simple semantics do not.** Third, developers 
 will steadily learn and forget languages. The overall number 
 of languages developers are familiar with is independent of 
 age. Finally, when considering intrinsic aspects of languages, 
 developers prioritize expressivity over correctness.




These conclusions seems correct to me.
May 24 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 20:30:14 UTC, deadalnix wrote:

 These conclusions seems correct to me.


They seem to only use quantitative data so it might not say much, 
or rather infer too much, but good research is difficult. For 
instance, how did those libraries come to exist? How do you 
discriminate between different levels of decision makers?  How do 
you distinguish between influencers and followers? Are decisions 
technical or social in reality? Are you sure that old and young 
programmers define programming skills on the same scale? Who 
choose to participate in surveys? Are open source projects 
representative of closed source? Is there a difference between 
hobby and professional activites?  Can you find  counterexamples? 
Are certain types of software dominating the survey, e.g. web?
Counter examples: Rust, C++, Haskell...

In short, it says nothing of use. We dont try to attract 50% of 
all programmers. Even 1% would be huge!
May 24 2022
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 21:53:36 UTC, Ola Fosheim Grøstad 
wrote:

 In short, it says nothing of use. We dont try to attract 50% of 
 all programmers. Even 1% would be huge!


Reread what I wrote in this channel and you'll note that this is 
very consistent with what I'm saying.

To be successful, you need to be really good at something. You 
need to be even better than everybody else at this thing. And the 
1% of people who really need this thing will be willing to 
overlook other shortcomings.

In turns, this grows the community, the codebase, the tooling and 
so on. This grant the resources to make the project good at a 
second thing and so on.

For instance, I remember about 10 years ago, when Rust was just 
starting, Andrei mentioned that Rust skipped leg day. This was 
funny and true: rust has that one thing about ownership it did 
extremely well, but everything else D was better. Where is rust 
now and where is D? Why did this happen? Well, the thing is, D is 
good at many thing, but it's not great at one thing. You 
therefore don't get that 1% of dev who really want or even need 
it.

The second thing is capitalizing on these devs. They will build 
tool and an ecosystem and this is a virtuous cycle. Except we 
keep breaking this cycles in a few ways:
1/ Ballooning complexity. The most jaring exemple is the 
attribute soup. The main problem is, most of the code out there 
is not quite attribute this or that compliant, so 
interoperability doesn't quite work, and making it work require 
major efforts, as anyone who contribute to phobos will be able to 
confirm.
2/ We do not get much benefit from that complexity, in any case, 
nothing that make it worth the cost. While we have attribute that 
are supposed to provide some guarantee, they are in practice 
often unable to provide said guarantee, either because there are 
hole in the implementation, but more often because there are 
fundamental design problems with them.
3/ We break these tools constantly, for weak reasons. Making a 
shorter in/out contract syntax. Making throw an exception. Named 
arguments. return is now an attribute. etc... All thee change 
break tools, and do not provide the kind of benefit that can 
counterract the loss of tooling.

These action taken effectively prevent the ecosystem from 
growing. Just like bonsai, it get trimmed on a regular basis, so 
it stays small.
May 24 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 24 May 2022 at 23:48:06 UTC, deadalnix wrote:


 To be successful, you need to be really good at something. You 
 need to be even better than everybody else at this thing. And 
 the 1% of people who really need this thing will be willing to 
 overlook other shortcomings.

 In turns, this grows the community, the codebase, the tooling 
 and so on. This grant the resources to make the project good at 
 a second thing and so on.


Don't be so pessimistic. `Balanced development` is not a bad 
thing.
`D` just not `organized`, and no better workflow.
May 24 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 24 May 2022 at 23:48:06 UTC, deadalnix wrote:

 Well, the thing is, D is good at many thing, but it's not great 
 at one thing. You therefore don't get that 1% of dev who really 
 want or even need it.


Yes, and since growth where there is a networking effect might 
follow the exponential-like S shape (sigmoid) we can also expect 
that libraries/frameworks happen when we enter the steep slope of 
the S curve. That one Rust feature is acting like a catalyst, you 
get higher density of a particular user type. Same with Go, since 
it was Google the initial influx was people with an interest in 
web or cloud, so that would be how it entered the S shape, the 
libraries/framework follow from that density of user types and 
boosted the already existing networking effect.

We dont really see a networking effect in D.

We dont see a condensation of a particular user type, except 
metaprogramming and language evolution, and that has boosted 
demands that doesn’t increase a particular niche fitness.


 These action taken effectively prevent the ecosystem from 
 growing. Just like bonsai, it get trimmed on a regular basis, 
 so it stays small.


Yes, it has to fix all the individual causes that prevents 
retention, then communicate a clear specific vision that fits a 
niche that is poorly covered. Could be gui apps on Linux or 
something else, but something specific is easier to target and 
measure than something abstract.

By being more specific you also can grow the ecosystem somewhat 
faster because the key demands are more focused.
May 24 2022
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 24 May 2022 at 21:53:36 UTC, Ola Fosheim Grøstad 
wrote:

 In short, it says nothing of use.


On the contrary, it says everything we need to hear. Open-source 
libraries matters most for D adoption. And that's about it. If 
you had written a bit of D code instead of a forum post for the 
last 10 years, we would have a better ecosystem.
May 25 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 May 2022 at 10:40:34 UTC, Guillaume Piolat wrote:

 On Tuesday, 24 May 2022 at 21:53:36 UTC, Ola Fosheim Grøstad 
 wrote:

 In short, it says nothing of use.


 On the contrary, it says everything we need to hear. 
 Open-source libraries matters most for D adoption. And that's 
 about it.


No, if I wrote yet another D game library, it would change 
nothing. This has already happened many times in the history of 
D. They all died. The current language + runtime is not in the 
top league for that purpose. This is why they dry up.

What has been said about Rust is spot on. You don’t fix this with 
producing more of what others have tried already.

You need to understand why you don’t retain those devs wanting to 
create games.
May 25 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 25 May 2022 at 10:55:46 UTC, Ola Fosheim Grøstad 
wrote:

 No, if I wrote yet another D game library, it would change 
 nothing. This has already happened many times in the history of 
 D. They all died.


https://code.dlang.org/packages/dagon updated 2 months ago. Seems 
hasty to pronounce it dead.

https://code.dlang.org/packages/godot-d Updated 5 months ago, but 
it does not really need to be updated commonly because it's a 
wrapper over Godot. I have played with godot a bit, it's an 
excellent engine and the D wrapper is practical to use.


 What has been said about Rust is spot on. You don’t fix this 
 with producing more of what others have tried already.


Hmm, the paper said "open-source libraries, existing code and 
experience". It could be that we already have the libraries, but 
more people would have to end up involved in projects that use D, 
to get the existing code and experience parts on track. But 
that's just a guess.


 You need to understand why you don’t retain those devs wanting 
 to create games.


FYI you're replying to an author of a D game over ten years old: 
https://www.auburnsounds.com/blog/2017-10-14_The-History-Of-Vibrant.html
May 25 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 25 May 2022 at 12:19:13 UTC, Dukc wrote:

 
 FYI you're replying to an author of a D game


https://p0nce.github.io/d-idioms/

Ola makes the valid point that open-source is hard (especially 
nowadays), and create a sufficient momentum to have an 
open-source libraries that extends its founder (forkable by 
others if need be, documented, bring ressources to itself instead 
of support work etc..) is a real challenge.
May 25 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 May 2022 at 12:32:03 UTC, Guillaume Piolat wrote:

 On Wednesday, 25 May 2022 at 12:19:13 UTC, Dukc wrote:

 
 FYI you're replying to an author of a D game


 https://p0nce.github.io/d-idioms/

 Ola makes the valid point that open-source is hard (especially 
 nowadays), and create a sufficient momentum to have an 
 open-source libraries that extends its founder (forkable by 
 others if need be, documented, bring ressources to itself 
 instead of support work etc..) is a real challenge.


Yes, better to find underserved niches like DPlug does, and saw 
seeds in audio/dsp forums and blogs. One doesn’t need a high rate 
of adoption, but it is important to retain the skilled ones. How 
many does DPlug need to become independent of the original 
author? 20 dedicated hardcore users? So if you manage to pick up 
6 and loose 2 every year it will take 5 years? A long term 
investment that makes sense if you intend to stay in that field 
for a long time, hobbyists seldom have long term goals measured 
in many years...

Also, the world has changed. Safari supports WebGL2 since last 
year, so browser games are good enough for many hobbyists now.
May 25 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 25 May 2022 at 13:06:41 UTC, Ola Fosheim Grøstad 
wrote:

 How many does DPlug need to become independent of the original 
 author?


Thinking too much about this nowadays :)

Realistically it take one well-selling product from someone else.

The best case scenario is a medium to large company to adopt and 
fork the open-source library, to eventually maintain it because 
it can't scale to their uses. Frameworks like this can be seen as 
asset by people with vertical ambitions (the sector tries 
concentrating). Good riddance :)

The worst case it, surprisingly, that more and more beginners 
would appear (or people posturing as beginners), taking an 
increasing amount of basic support until the maintainer resign. 
This is actually the number one risk, and one possible 
counter-measure is to make everyone pay and give them no access 
to the bugtracker, like JUCE does.

So there is a "debt vs asset" position to account for, it is that 
the current community must be able to create net-positive 
contributions.

I'm always on the look out for ways to incenticize sticking 
around, making contributions, and basing revenue streams on top 
of Dplug. It's not easy to explain this to well-meaning, but 
demanding users. It might mean showing people the door.

So currently, 5 developers that I know of use the framework to 
make products for themselves ; none came from the D community. 
These are only the uses I know about, some people don't want to 
engage with a community.

Even today, Dplug could be deleted and forks would appear, 
because revenue streams depend on it, but it probably doesn't yet 
cover the full cost of evolutive maintenance - it is about 6 
man-month a year. So I'm not sure if it would last long, and that 
is a problem indeed. Revenue stream is the mechanical force that 
motivates for years. Now you must explain to users how to compete 
with you...

Dplug is a by-product of plugins that sell, it couldn't exist 
otherwise. If Vibrant had sold more than 200 copies :) perhaps it 
could have a framework too. But it was a bitter commercial 
failure and couldn't justify the maintenance, so everything about 
it is retired.

(To make a net-positive game framework, one would have to target 
game developers and the middleware market, which is a lot easier 
than the game market.)

Cost of making the by-product available in open-source is there, 
but you have unintended positive consequences too (more 
ecosystem, input, community, things happening).
May 25 2022
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 25 May 2022 at 13:57:30 UTC, Guillaume Piolat wrote:

 So currently, 5 developers that I know of use the framework to 
 make products for themselves ; none came from the D community. 
 These are only the uses I know about, some people don't want to 
 engage with a community.


Aren't you worried that by using DPlug they discover D and sue it 
to steal the market share that would have gone to Auburn Sounds 
if they had stayed with C++?

:D
May 25 2022
next sibling parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 25 May 2022 at 14:14:28 UTC, Dukc wrote:

 discover D and sue it


Meant use it.
May 25 2022
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 25 May 2022 at 14:14:28 UTC, Dukc wrote:

 Aren't you worried that by using DPlug they discover D and use 
 it to steal the market share that would have gone to Auburn 
 Sounds if they had stayed with C++?


Companies that already exist will keep their codebase and not use 
D.

So it's only new entrants, it's more likely to take market share 
from C++ey shops.
Moreover, audio companies disappear because of internal 
disagreements, very rarely market conditions.
May 25 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 May 2022 at 13:57:30 UTC, Guillaume Piolat wrote:

 So there is a "debt vs asset" position to account for, it is 
 that the current community must be able to create net-positive
 


Maybe your company could take the role of a publisher? So if I 
create a novel effect it would go into one of your stacks with a 
certain percentage?

Then I don’t have to deal with marketing, windows etc and you 
would get a cut? Or is that unrealistic?



 Now you must explain to users how to compete with you...


Yes... it would be better to cooperate and share marketing costs, 
some kind of umbrella brand? Or is it better to be small perhaps. 
I know nothing about this...


 If Vibrant had sold more than 200 copies :) perhaps it could 
 have a framework too. But it was a bitter commercial failure 
 and couldn't justify the maintenance, so everything about it is 
 retired.



I haven’t heard of Vibrant, but I guess it is typical in 
publishing to have a few products that makes up for all the 
others.

Seems to me that pooling would reduce the risk, but I guess 
cooperation online is a challenge...

If I knew how to make money off audio then I would give it a try 
by making weird effects for sure!!😁


 Cost of making the by-product available in open-source is 
 there, but you have unintended positive consequences too (more 
 ecosystem, input, community, things happening).


Understand, seems like attracting knowledgable hobby-users early 
on is important so that support is not done by devs...
May 25 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 25 May 2022 at 17:27:58 UTC, Ola Fosheim Grøstad 
wrote:

 Maybe your company could take the role of a publisher? So if I 
 create a novel effect it would go into one of your stacks with 
 a certain percentage?
 Then I don’t have to deal with marketing, windows etc and you 
 would get a cut? Or is that unrealistic?


Some actors of the industry have done that and it is very 
lucrative for them. A big subscription separated through allies. 
But then you have to grow a lot to make acquisition. It's a more 
important power imbalance than just relying on other's code 
though.
At the end of the day, noone will really do your marketing for 
you.



 Yes... it would be better to cooperate and share marketing 
 costs, some kind of umbrella brand? Or is it better to be small 
 perhaps.


It's too early to tell.
What I'd like to push meanwhile is more sharing of (unmaintained) 
private UI code.
May 25 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 May 2022 at 20:13:46 UTC, Guillaume Piolat wrote:

 At the end of the day, noone will really do your marketing for 
 you.


Maybe with the ui scripting you could boil down one effect to a 
couple of files and have many effects by different authors in the 
same plugin. Then sell collections: 8xvocoders, 80s-reverbs, 20 
analog guitar effects.

Anyway, the idea could be to view dplug as a gateway to a 
service. I guess the review would have to be by audio sample... 
to make it managable...

Anyway, something cooperative could make dplug interesting to 
more people.
May 25 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 25 May 2022 at 10:40:34 UTC, Guillaume Piolat wrote:

 On Tuesday, 24 May 2022 at 21:53:36 UTC, Ola Fosheim Grøstad 
 wrote:

 In short, it says nothing of use.


 On the contrary, it says everything we need to hear. 
 Open-source libraries matters most for D adoption. And that's 
 about it. If you had written a bit of D code instead of a forum 
 post for the last 10 years, we would have a better ecosystem.


While I wouldn't go as far to say that it's everything we have to 
know, it's still real research. Definitely much better than 
typical forum theorising. Thanks for bringing it up.
May 25 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 May 2022 at 12:23:21 UTC, Dukc wrote:

 While I wouldn't go as far to say that it's everything we have 
 to know, it's still real research.


Most research is not useful in isolation. Scientific research 
aims at pointing to causal factors, not correlation or averaging 
self selected self evaluation.   Correlation can be highly 
misleading, sadly.

It is useful to think of growth models like the ones you find in 
biology and other fields. So, if we think of D programmers as 
species and then think about population densities then we have 
something that can help.

D may have had enough game programmers over time, but not in 
sufficient density. Dplug is doing the clever thing, trying to 
create immigration to the D island from the mainland where food 
is scarce. But those birds need help crossing the ocean so it 
isn’t cheap... you need enough birds to weather a storm, so you 
cannot stop helping prematurely... so you are bound to a long 
term investment.


Doing the same for gaming is perhaps even more difficult, there 
is plenty on the mainland so why would the birds cross the ocean? 
We need something others don’t have that is very tasty... what 
exactly would that be?

D has attracted many species, but low concentrations of each. If 
you are below a threshold you will not produce. If you seed with 
random species maybe some will take hold given enough time, if 
the environment is stable, if it isnt you typically will get a 
rotation, but no big concencentration...

There is a reason why the D standard lib is the most successful 
collaboration.
May 27 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 May 2022 at 10:22:31 UTC, burjui wrote:

 Why D is unpopular? Because people don't stay. As I can only 
 truly speak for myself, here's the reason why I left:
 https://issues.dlang.org/show_bug.cgi?id=2043

 This bug is 14 years old already, and the memory-corrupting 
 code still compiles, unless you enable DIP1000 (not a standard 
 yet).


It's becoming one. The latest Dmd, 2.100, already prints a 
deprecation message about DIP1000-noncompatible code unless you 
explicitly add `-revert=dip1000`. And it's quickly becoming 
stable too. Only three or four releases ago, you continuosly 
discovered bugs if trying to seriously use DIP1000 but in my 
experience, there's only a fraction of that anymore.


 There are many more papercuts like that in D: incomplete and 
 poorly designed features, bugs that don't get fixed, the 
 overall lack of computer science backing, resulting in what I 
 would call a complex graph of hacks rather an elegant language.


I partially agree with that. But on the practical side, the 
features are often complete enough to be useful. For example, 
even with all it's shortcomings, I still vastly prefer `-betterC` 
to C!

And when the features are too incomplete for use, you can simply 
ignore them.


 And one of the main problems, imho, is Walter himself. He's 
 like a child that wants to play with his favourite toys, e.g. 
 ImportC, but hates doing homework. That's why we have many 
 shiny new features in D, but bugs can rot their way into DMD 
 for decades. I get that behaviour, I was like that most of my 
 life. Judging from my own experience, he may even have 
 untreated ADHD. He's great at programming, but sucks at 
 leadership. And D is no longer his own toy, it's a project with 
 many people depending on it. Whatever the problem with Walter 
 is, it's outright irresponsible to have him as a leader.


You're way too harsh. Anyone here with experience about the 
subject can tell that Walter has made many highly controversial 
decisions. But I suspect it's simply because language leadership 
is incredibly hard. Most people would probably not have some of 
the Walter's blind spots, but they would have other weaknesses 
and would almost certainly lack some of the exceptional qualities 
of Walter. Compiler knowledge, persistance and experience for 
example. And even if you find someone more capable, the chances 
of him/her being willing for the thankless job are slim.
May 24 2022
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 May 2022 at 11:51:43 UTC, Dukc wrote:

 On Tuesday, 24 May 2022 at 10:22:31 UTC, burjui wrote:

 Why D is unpopular? Because people don't stay. As I can only 
 truly speak for myself, here's the reason why I left:
 https://issues.dlang.org/show_bug.cgi?id=2043

 This bug is 14 years old already, and the memory-corrupting 
 code still compiles, unless you enable DIP1000 (not a standard 
 yet).


 It's becoming one. The latest Dmd, 2.100, already prints a 
 deprecation message about DIP1000-noncompatible code unless you 
 explicitly add `-revert=dip1000`. And it's quickly becoming 
 stable too. Only three or four releases ago, you continuosly 
 discovered bugs if trying to seriously use DIP1000 but in my 
 experience, there's only a fraction of that anymore.


DIP1000 is bad. It can detect a few trivial case, but beside 
that, it is unable to detect anything. As a result, it cannot 
solve this specific problem, only simple instance of it. The 
expect impact is therefore an increase in the complexity of the 
language without providing the kind of value you'd expect out of 
it.

I was told to submit bug report, but this is not a bug. There is 
no amount of bug that you can fix in DIP1000 to make it do what 
it is supposed to do. Just like there is no amount of bug report 
I can submit to a regex that tries to parse D.

I have no doubt this is going to happen though, and it will break 
tools and code, and it won't bring the value that it is supposed 
to, because it can't, and validate everything in this thread. I 
hope you prove me wrong, please do.
May 24 2022