www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback from the Gripes and Wishes Campaign

reply Mike Parker <aldacron gmail.com> writes:
I've finally compiled all of the feedback from the Gripes and 
Wishes campaign into a single document for your perusal. Thanks 
to everyone who sent something to me. If you did send feedback 
and don't see it here, please let me know.

https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md

A few notes:

* I've excluded Bugzilla issues that have since been closed
* I've tried to include examples and suggestions that were 
provided along with the points, but I have cut out some bits that 
were irrelevant or extraneous.
* I've not included compliments. I wanted to focus only on things 
we need to fix/change. But the compliments were received and much 
appreciated.
* There were three pieces that I decided not to breakdown into 
actionable items and included in longform instead. Those are at 
the bottom of the document.
* I'll probably update this list after our planning meeting 
tomorrow.

So, the next steps related to this. Generally, we need to:

* establish some high-level goals
* go through this list to see what fits with those goals, what 
doesn't fit now but could be done later, and what is unlikely to 
ever fit any goals
* discuss additional ideas from our own wish lists (and I'll 
update the document with those once I have them all)
* prioritize everything we've decided fits our current goals
* publish categorized task lists
* work out who among us is responsible for what
* get things done

That last one is the hard part. I'll have more to say about it 
when the time comes.
May 18 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 I've finally compiled all of the feedback from the Gripes and 
 Wishes campaign into a single document for your perusal. Thanks 
 to everyone who sent something to me. If you did send feedback 
 and don't see it here, please let me know.

 https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md

 A few notes:

 * I've excluded Bugzilla issues that have since been closed
 * I've tried to include examples and suggestions that were 
 provided along with the points, but I have cut out some bits 
 that were irrelevant or extraneous.
 * I've not included compliments. I wanted to focus only on 
 things we need to fix/change. But the compliments were received 
 and much appreciated.
 * There were three pieces that I decided not to breakdown into 
 actionable items and included in longform instead. Those are at 
 the bottom of the document.
 * I'll probably update this list after our planning meeting 
 tomorrow.

 So, the next steps related to this. Generally, we need to:

 * establish some high-level goals
 * go through this list to see what fits with those goals, what 
 doesn't fit now but could be done later, and what is unlikely 
 to ever fit any goals
 * discuss additional ideas from our own wish lists (and I'll 
 update the document with those once I have them all)
 * prioritize everything we've decided fits our current goals
 * publish categorized task lists
 * work out who among us is responsible for what
 * get things done

 That last one is the hard part. I'll have more to say about it 
 when the time comes.


"Ah yes, this is one of mine, this is one of mine, this is one of 
mine where I made a typo... God damn it."

Big list! What's interesting to me is the entries that I would 
straight up disagree with, like removing contracts. Brings to 
mind the common claim that D is too big, it has too many features 
that nobody use, we could totally remove these ten features 
without anybody complaining ... followed by a list that is 
different for everyone. :)
May 18 2023
prev sibling next sibling parent Anonymouse <zorael gmail.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 [...]


Thanks for compiling this!
May 18 2023
prev sibling next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 I've finally compiled all of the feedback from the Gripes and 
 Wishes campaign into a single document for your perusal. Thanks 
 to everyone who sent something to me. If you did send feedback 
 and don't see it here, please let me know.

 https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md

 A few notes:

 * I've excluded Bugzilla issues that have since been closed
 * I've tried to include examples and suggestions that were 
 provided along with the points, but I have cut out some bits 
 that were irrelevant or extraneous.
 * I've not included compliments. I wanted to focus only on 
 things we need to fix/change. But the compliments were received 
 and much appreciated.
 * There were three pieces that I decided not to breakdown into 
 actionable items and included in longform instead. Those are at 
 the bottom of the document.
 * I'll probably update this list after our planning meeting 
 tomorrow.

 So, the next steps related to this. Generally, we need to:

 * establish some high-level goals
 * go through this list to see what fits with those goals, what 
 doesn't fit now but could be done later, and what is unlikely 
 to ever fit any goals
 * discuss additional ideas from our own wish lists (and I'll 
 update the document with those once I have them all)
 * prioritize everything we've decided fits our current goals
 * publish categorized task lists
 * work out who among us is responsible for what
 * get things done

 That last one is the hard part. I'll have more to say about it 
 when the time comes.


It's good to see that this thing from about half a year ago 
finally seen some traction. Thank you for your work. But then 
again, reading other threads (such as this one 
https://forum.dlang.org/thread/lktxmzdcmaagtrswpily forum.dlang.org) leaves me
with about 0 hope that any of this is going to be taken into account. Was this
brought up anywhere internally? Was there any discussion? What are the results
of the discussion?

Having a list is good, but I'm afraid this will die as a list.
May 18 2023
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 18 May 2023 at 14:07:09 UTC, GrimMaple wrote:


 It's good to see that this thing from about half a year ago 
 finally seen some traction. Thank you for your work. But then 
 again, reading other threads (such as this one 
 https://forum.dlang.org/thread/lktxmzdcmaagtrswpily forum.dlang.org) leaves me
with about 0 hope that any of this is going to be taken into account. Was this
brought up anywhere internally? Was there any discussion? What are the results
of the discussion?

 Having a list is good, but I'm afraid this will die as a list.


We'll start discussing it tomorrow, and in several weekly 
planning meetings going forward. The steps I outlined at the 
bottom of the post are all about that.
May 18 2023
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 I've finally compiled all of the feedback from the Gripes and 
 Wishes campaign into a single document for your perusal.



This is more important than ivy, and `priority weights list` need 
to be evaluated.
May 18 2023
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 18 May 2023 at 14:38:16 UTC, zjh wrote:


 This is more important than ivy, and `priority weights list` 
 need to be evaluated.



This feels a bit like engineering project management.
May 18 2023
parent zjh <fqbqrr 163.com> writes:
On Thursday, 18 May 2023 at 14:40:12 UTC, zjh wrote:


 This feels a bit like engineering project management.



I think the main problem is still the `lack` of user 
participation and tutorials. There are already `video tutorials`, 
but I think the author of `D` should write some more tutorials. 
For example, where do you want to improve? The author of `D` 
should explain how to modify them and pay attention to certain 
areas. The D community needs people, not doing everything 
personally.
  D Author can write a series of tutorials targeting multiple 
obvious potential `improvement points`, explaining how to improve 
them in `D`, rather than just welcoming them modifying, because 
they don't know how to improve them at all.
May 18 2023
prev sibling next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
 I wish Dub would create import libraries for Windows.


This should be the case.

If you need it in a scenario where it doesn't for DLL's, please file a 
bug report as it is a bug. It just requires tuning as to when to copy 
them (the linker will generate them if it sees exports).

Static libraries and object files don't have them, executables don't 
have a use case for them currently.




 I believe dub could really get a target type which builds all static 


libraries dependencies and a main static library.

I'm waiting on Martin to get back to us about his work experimenting 
with shared library support in dub before working on a new target type 
that will allow this to happen.

https://github.com/dlang/dub/issues/2633
May 18 2023
prev sibling next sibling parent reply user456 <user456 123.de> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 I've finally compiled all of the feedback from the Gripes and 
 Wishes campaign into a single document for your perusal. Thanks 
 to everyone who sent something to me. If you did send feedback 
 and don't see it here, please let me know.

 https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md

 A few notes:

 * I've excluded Bugzilla issues that have since been closed
 * I've tried to include examples and suggestions that were 
 provided along with the points, but I have cut out some bits 
 that were irrelevant or extraneous.
 * I've not included compliments. I wanted to focus only on 
 things we need to fix/change. But the compliments were received 
 and much appreciated.
 * There were three pieces that I decided not to breakdown into 
 actionable items and included in longform instead. Those are at 
 the bottom of the document.
 * I'll probably update this list after our planning meeting 
 tomorrow.


I have detected an incomplete sentence:

"According to Walter in the January 2023 Quartely Meeting, sum 
types won't be the focus in D anytime soon, in favor of 
robustness. That's"
May 18 2023
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 18 May 2023 at 17:16:24 UTC, user456 wrote:


 I have detected an incomplete sentence:

 "According to Walter in the January 2023 Quartely Meeting, sum 
 types won't be the focus in D anytime soon, in favor of 
 robustness. That's"


Thanks! The complete text is:

"According to Walter in the January 2023 Quartely Meeting, sum 
types won't be the focus in D anytime soon, in favor of 
robustness. That's 100 % reasonable. But if sum types appear, 
non-nullable class references can go hand-in-hand with them: The 
nullable reference ("X" in D2, in other languages "X?") is really 
a sum type of the non-nullable reference ("X") and typeof(null). 
And "?" can become universal shorthand for "sum type with 
typeof(null)" not only for non-nullable class references, but for 
any type."
May 19 2023
prev sibling next sibling parent reply Theo <Theo gmail.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 ...


I do not accept the proposition (of some) -> 'no vision, no 
motivation'.

Putting that aside....

D has little to no chance of ever having persistent, large-scale 
traction.

It simply cannot compete with the other languages out there, in 
that arena.


persistent and large-scale use) well... that's absurd.

D's is an experimental language. The should become the ideal 
vision of itself.

Once everyone finally realises this, that realization is what 
will take D forward.

Taking D forward, will not come about by creating a vision for 
persistent, large-scale traction. That is a delusion, created in 
peoples minds.

D has also long-needed an experimental branch, to help motivate 
ideas, participation, and use. ImportC should have gone straight 
into an experimental branch, and no found its way into production 
branch until it does what it claims to do (which is still 
doesn't!).

If I had been in charge 10 years ago, the above is where my focus 
would have been,
and all the other languages (though used far more than D), would 
all be looking at D for new ideas.

D also needs (long overdue IMO) a rotating stewardship, like they 
have in FreeBSD.

Those stewards have a fixed time to make their mark, and then 
others get a change as well.

Instead, stagnation in stewardship is what has come to define the 
D programming language.
May 18 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 18 May 2023 at 23:12:15 UTC, Theo wrote:

[...]

Great, a long treatise unrelated to Mike's post, written with the 
intention of Google bringing it up for the next 10 years.
May 18 2023
next sibling parent Theo <Theo gmail.com> writes:
On Friday, 19 May 2023 at 00:10:52 UTC, bachmeier wrote:

 On Thursday, 18 May 2023 at 23:12:15 UTC, Theo wrote:

 [...]

 Great, a long treatise unrelated to Mike's post, written with 
 the intention of Google bringing it up for the next 10 years.


?? what ??

Everyone else gripes are welcome.. except mine?
May 19 2023
prev sibling parent Theo <Theo gmail.com> writes:
On Friday, 19 May 2023 at 00:10:52 UTC, bachmeier wrote:

 On Thursday, 18 May 2023 at 23:12:15 UTC, Theo wrote:

 [...]

 Great, a long treatise unrelated to Mike's post, written with 
 the intention of Google bringing it up for the next 10 years.


also. I don't get how my gripes are unrelated to post about 
gripes.

I also don't get the reference to google??

And btw. I've been using D for over a decade. So expect me to 
have gripes, just like anyone else (including yourself, no doubt).

Nothing in the past 5 years has motivated me, in any way at all, 
in regards the D programming language. That' really sad.

Anyway, I'll keep 'waiting....' I guess, till the next big 
announcement about >?>>>>??
May 19 2023
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/18/23 16:12, Theo wrote:


 D's is an experimental language.


Sure.


 The should become the ideal vision of
 itself.


Speaking of selves, do you think your writing under pseudonyms is about 
your having a strong self? A little far-fetched but there is a theory 
out there about this thing called "unself" which you may find useful.


 If I had been in charge 10 years ago, the above is where my focus would
 have been,


I wish that were the case but for all I know, you are a bot that uses 
the pseudonym Theo these days. (I need to look in my Outlook filters for 
the earlier ones.)


 and all the other languages (though used far more than D), would all be
 looking at D for new ideas.


Don't they already do that? You mentioned C++ earlier... Don't you think 
they have been taking ideas from D?

Ali
May 18 2023
parent Theo <Theo gmail.com> writes:
On Friday, 19 May 2023 at 00:19:41 UTC, Ali Çehreli wrote:

 Don't they already do that? You mentioned C++ earlier... Don't 
 you think they have been taking ideas from D?

 Ali


Yes. Precisely. That is my point.

I'd like those ideas to keep coming, and find there way into 
'expermental' branch of D, and once they've demonstrated their 
worth (and correctness), put into 'production' D.

This is 'my' 'ideal' 'vision', of how I'd like to see D continued 
forward.

btw. If bots could think and write like I do, then humans would 
not be necessary anymore ;-)
May 19 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 18 May 2023 at 23:12:15 UTC, Theo wrote:

 D has little to no chance of ever having persistent, 
 large-scale traction.

 It simply cannot compete with the other languages out there, in 
 that arena.


I disagree, strongly. D suits several areas incredibly well, even 
as is. For example, I built this 
https://github.com/GrimMaple/mwverify UI (!) app in about 20 
minutes from scratch. And it uses zero C dependencies, it's Full 
D.

Besides that, D suits game developemnt really well, thanks to its 
easily controllable garbage collection and access to low level 
features to speed up your code when necessary. And while the GC 
implementation is sometimes lacking, just having a GC that you 
can decide when to run, gives you a great coding speed advanatage 
over C/C++, where you would spend most of your time thinking 
about proper memory management (shared pointers aren't proper 
memory management).


natively. And with the use of LDC, you can achieve executables as 
lightning fast as C/C++ executables.



 persistent and large-scale use) well... that's absurd.




_slow_.


 D's is an experimental language. The should become the ideal 
 vision of itself.


While this is de-facto true, it doesn't have to be like that. I 
have been vouching for a stable D branch for about a year now, 
because I'm sick of having to fix my frameworks with literally 
__every__ new compiler version. The older the framework, the more 
breakage happens.


 Once everyone finally realises this, that realization is what 
 will take D forward.

 Taking D forward, will not come about by creating a vision for 
 persistent, large-scale traction. That is a delusion, created 
 in peoples minds.


I think that the purpose of a language is to create software. And 
D doesn't really help with achieveing that. The language itself 
does, but the infrastructure around it and its release cycles 
clearly don't. Recently, dmd deprecated `alias this` for classes. 
Do you have any idea how devastating that change was for any 
third party that used it? Now, if such feature was used, any 
class that used it would have to be split to `before` and `after` 
branches, creating quite a lot of tech debt, deprecation 
messages, and `version` to make this monstrocity at least 
remotely usable. And how do you expect me to even think about 
wrting third party when I know it will be broken by language 
developers in near future? Again, such breaking has been 
happening to `dlangui` with almost every new version of the 
compiler. I'm getting tired of fixing breakage instead of fixing 
`dlangui` itself.

And do I have to mention that I have to make sure that the 
framework code compiles with older compilers? Because people 
might use `apt install dmd`, and get a compiler that's about 1 
year out of date. That requires me to have different versions of 
compiler set-up, and I have to make sure that users are able to 
compiler & run my framework.


 D has also long-needed an experimental branch, to help motivate 
 ideas, participation, and use. ImportC should have gone 
 straight into an experimental branch, and no found its way into 
 production branch until it does what it claims to do (which is 
 still doesn't!).


I don't think that is necessary. D already has everything it 
needs to gently slide in experimental changes/features. It's just 
not being used properly. For compiler features, there are 
`preview` switches. For phobos, there's `std.experimental`.

Unfortunately, big compiler changes, like mentioned above 
deprecation of alias this, or ImportC for that matter, weren't 
hidden behind a preview switch. Heck, ImportC didn't even go 
through DIP process! And `std.experimental` is a synonim for 
graveyard, from where nothing gets out to actual `std`. Logger is 
the only exception to the case, I think.


 Instead, stagnation in stewardship is what has come to define 
 the D programming language.


I don't think that it can be attributed to stagnation itself, I 
think Walter (and other core D devs) need to get out of the 
compiler / phobos and start writing something useful in D. Apps, 
frameworks, websites, whatever. Something that can be put on the 
dlang.org main page under "Apps written in Full D". This way they 
would learn how frustrating D is in real world, and maybe they 
will stop breaking stuff and introducing features nearly nobody 
asked for.
May 19 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 19 May 2023 at 11:43:06 UTC, GrimMaple wrote:

 I don't think that it can be attributed to stagnation itself, I 
 think Walter (and other core D devs) need to get out of the 
 compiler / phobos and start writing something useful in D. 
 Apps, frameworks, websites, whatever. Something that can be put 
 on the dlang.org main page under "Apps written in Full D". This 
 way they would learn how frustrating D is in real world, and 
 maybe they will stop breaking stuff and introducing features 
 nearly nobody asked for.


I haven't read Mike's post yet, i will right after this, but i 
wanted to address your reply first, because it kinda pains me

There are some features that are essential to be able achieve the 
vision D wants to achieve (pay as you go)

For example:

- **exception handing**: why use EH when you can have your 
function return 2 values (error and result)

- **gc**: why use classes/interfaces/new when you can just use a 
tagged union and pattern matching coupled with an Allocator API


This alone makes it so we can build a foundation of libraries 
that are both pragmatic and adhere to a "pay as you go" vision 
for the user

Now the GC discourse is no more! want to use a GC? just pass 
GCAllocator, wants to do it manually because you have certain 
requirement? (game) use this GeneralPurposeAllocator, or make 
your very own

Pragmatism is great, lets the user choose about what path to take 
rather than enforcing a path to the user with a specific 
assumption



 Besides that, D suits game developemnt really well, thanks to 
 its easily controllable garbage collection and access to low 
 level features to speed up your code when necessary


Yes and No, for D it's not since it is blocking

You want to have full control over your memory allocation 
strategy anyways

Read about how people workaround GC problems in both 
Unreal/Unity, let's not come up with the same problems, that's 
not how you'll win users, why would they use something less 
popular, that has the same problems but worse?

Being pragmatic, and having an allocator API would solve the GC 
problem people have in both Unreal/Unity, they don't so they 
waste time workingaround

Be the solution to their problems, not a copy pasta, i always 
seen D as being the pragmatic solution, hence i choose to stick 
with D ~4 years ago, it's unfortunatly winding down as i read 
more people who are against having essential and foundational 
features
May 19 2023
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 There are some features that are essential to be able achieve 
 the vision D wants to achieve (pay as you go)


I think the problem with the D community is that they are not 
bold enough. If you have an idea just do it, don't wait for any 
approval from Walter or the maintainers because they are going to 
say no anyway or not saying anything at all. If you have made a 
PR that is popular, the maintainers have no power to stop it 
which will only lead to that D eventually will be forked.

One problem with this is that writing compilers requires 
knowledge but if you have the knowledge, don't wait for Walter 
(he's busy with importC anyway) or the maintainers. If you are 
waiting for some plan, approval whatever, just forget it. Instead 
work with the community and the community can sort out what 
changes works and which don't.

An analogy is Tesla, that kicked the entire car industry in the 
nuts. This was very much needed for the otherwise conservative 
and slow moving industry.
May 19 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 19 May 2023 at 18:37:05 UTC, IGotD- wrote:

 If you have made a PR that is popular, the maintainers have no 
 power to stop it which will only lead to that D eventually will 
 be forked.


I roflmaoed. Walter has literally been blocking changes and even 
__reverting commits__ based on personal preference, despite the 
majority of the community agreeing on the change. Important 
people left because of this in the past.
May 19 2023
parent deadalnix <deadalnix gmail.com> writes:
On Friday, 19 May 2023 at 19:01:46 UTC, GrimMaple wrote:

 On Friday, 19 May 2023 at 18:37:05 UTC, IGotD- wrote:

 If you have made a PR that is popular, the maintainers have no 
 power to stop it which will only lead to that D eventually 
 will be forked.


 I roflmaoed. Walter has literally been blocking changes and 
 even __reverting commits__ based on personal preference, 
 despite the majority of the community agreeing on the change. 
 Important people left because of this in the past.


Good. As Coluche said, it's not because they are many to be wrong 
that they are right.

I do not know if Walter was justified in each of these instance 
specifically, but there needs to be someone guarding things 
aligned with the vision, and it's never "the community" that does 
that.

I'd be much more worried of any project where the leader does NOT 
do this from time to time.
May 24 2023
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, May 19, 2023 at 06:37:05PM +0000, IGotD- via Digitalmars-d wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 
 There are some features that are essential to be able achieve the
 vision D wants to achieve (pay as you go)
 


 
 I think the problem with the D community is that they are not bold
 enough.  If you have an idea just do it, don't wait for any approval
 from Walter or the maintainers because they are going to say no anyway
 or not saying anything at all. If you have made a PR that is popular,
 the maintainers have no power to stop it which will only lead to that
 D eventually will be forked.


+1. I was just a random nobody who found D online, ran into problems,
and decided that instead of waiting for somebody else to fix my problems
for me, I'll fix them myself and submit PRs.  Then when my PRs were
getting ignored, I pestered the maintainers until they responded. When
they didn't respond I made a louder noise.  Eventually, I made a loud
enough noise that one fine day Andrei suddenly decided to give me the
keys to the kingdom, so to speak, and I became one of the Phobos
committers.  Haven't really been doing much these days with that,
though, but still.  Taking the initiative is what will change things;
sitting around hoping somebody else will do the work generally ends in
disappointment. Besides, fixing it yourself will get you the solution
faster (there was a period of time I was using my local modification of
the dmd toolchain 'cos upstream was b0rken and I couldn't wait for the
fix to be officially merged), and on top of that earns you creds with
the maintainers and the community.



 One problem with this is that writing compilers requires knowledge but
 if you have the knowledge, don't wait for Walter (he's busy with
 importC anyway) or the maintainers. If you are waiting for some plan,
 approval whatever, just forget it. Instead work with the community and
 the community can sort out what changes works and which don't.


[...]

I'd say, if you don't have the knowledge, why not spend the time to
acquire it?  Regardless of the outcome, this knowledge will be very
useful to you wherever you may end up. Understanding how compilers
actually work will help you understand why programming languages are the
way they are, and how to exploit this to your own advantage instead of
chafing every time something doesn't work your way.

Don't sit around waiting for the bull to end up where you want it to;
grab the bull by its horns and *make* it go where you want.


T

-- 
When solving a problem, take care that you do not become part of the problem.
May 19 2023
parent reply Theo <Theo gmail.com> writes:
On Friday, 19 May 2023 at 19:03:42 UTC, H. S. Teoh wrote:

 
 ..
 Don't sit around waiting for the bull to end up where you want 
 it to; grab the bull by its horns and *make* it go where you 
 want.


 T


+1

And here is an example (of someone taking the bull by the horn):

https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

Now, the motivations for the person that did this, was just so 
see 'how it could be done', and not necessarily because that 
person wanted that feature. Nonetheless, stagnation on a long, 
and very fiercly discussed issue, over many years, finally made 
some progress.

In the meantime, Walter and Magic Mike just made videos about how 
D will never, ever, ever, ever... allow you to have class private 
members within a module (like I can do in Swift).

Fortunately, somebody followed the Nike Theory : Just do it!, 
and.. dada! It was done!

Now, unfortunately, D has no 'experimental' release, so 
programmers who like how this *helps them* better express their 
code, never got a chance to use it - and still don't.

It was never a wild, ridiculous concept either. Just the option 
to have a private member to a class within a module! I mean... 
jezzzz! And soo..... much obstruction, like I've never seen 
before, on any issue, ever discussed in the D forums!

All it took for it to happen, was someone to 'Just do it!'.

I cannot recall IVY being a motivating force behind it.

Please, more action, less obstruction, and ... less talk about 
ideal visions of oneself.

That's the end of my gripes... for now.
May 19 2023
next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 20 May 2023 at 00:49:09 UTC, Theo wrote:



 And here is an example (of someone taking the bull by the horn):

 https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242


After you shouted `100` times, no one else paid attention to you, 
and in the end, you had to leave.
May 19 2023
prev sibling parent IGotD- <nise nise.com> writes:
On Saturday, 20 May 2023 at 00:49:09 UTC, Theo wrote:

 Now, unfortunately, D has no 'experimental' release, so 
 programmers who like how this *helps them* better express their 
 code, never got a chance to use it - and still don't.


This is exactly what I would think would be helpful, a new branch 
for experimental and disruptive features. A branch that is 
outside the control of the maintainers or at least they don't 
care about it. A branch where D can evolve and diverge from D2.

The best would be if the branch could be located at the official 
D repo at github but safest would be it should be hosted in a 
separate fork. The question is how we can replicate the CI system 
in order to suit the needs.
May 20 2023
prev sibling parent reply Commander Zot <no no.no> writes:
On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


oh god no. it leads to horrible code. just take a look at go.
May 25 2023
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


 oh god no. it leads to horrible code. just take a look at go.


Go is an unusually atrocious implementation. In a not terrible 
language, it just looks like `foo()?.bar()?.baz`.
May 26 2023
next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:

 Go is an unusually atrocious implementation. In a not terrible 
 language, it just looks like `foo()?.bar()?.baz`.


The whole point of exceptions was to remove that kind of 
syntactic noise. I still don't understand why people want to 
throw away the convenience instead of fixing problems it has.
May 26 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 27/05/2023 1:28 AM, Max Samukha wrote:

 On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:

 Go is an unusually atrocious implementation. In a not terrible 
 language, it just looks like `foo()?.bar()?.baz`.


 
 The whole point of exceptions was to remove that kind of syntactic 
 noise. I still don't understand why people want to throw away the 
 convenience instead of fixing problems it has.


Replacement of the exception mechanism does not imply replacing 
exception syntax.

You can still have throw/try/catch syntax and use sumtypes to return a 
value or exceptions structs.

I.e. 
https://github.com/rikkimax/DIPs/blob/value_type_exceptions/DIPs/DIP1xxx-RC.md
May 26 2023
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:

 On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


 oh god no. it leads to horrible code. just take a look at go.


 Go is an unusually atrocious implementation. In a not terrible 
 language, it just looks like `foo()?.bar()?.baz`.


The problem of the optional access is understanding the side 
effects. It looks simple to use, and it really is, at first 
glance. The problem is that things are not necesarilly made to be 
shortcut (btw are they really shortcut ?).

So...

1. with calls the problem is that actually it looks like very 
safe while it should be only used by the people who know very 
well the API... like maybe the thing should be called and having 
null as parameter is actually a meaningfull error (after all)
2. optional accesses chains are not as well optimisable as AndAnd 
chains (which them are really shortcut)

it's a matter of knowing where to use them, like in cold paths 
it's ok.
But well maybe it's just my implementation that's bad.

Slightly off-topic but the question mark uses I really like, as 
said a few days ago, are `?=` and the elvis (`??` or `?:`, etc. 
there might exist other syntaxes)
May 26 2023
prev sibling parent reply Commander Zot <no no.no> writes:
On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:

 On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


 oh god no. it leads to horrible code. just take a look at go.


 Go is an unusually atrocious implementation. In a not terrible 
 language, it just looks like `foo()?.bar()?.baz`.


now take the `foo()?.bar()?.baz` example, but change it to log 
which part failed. it only looks simple for the most basic case, 
the second you need to do rollbacks or really anything else this 
approach gets so much more complicated.
May 30 2023
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 30 May 2023 at 09:13:03 UTC, Commander Zot wrote:

 now take the `foo()?.bar()?.baz` example, but change it to log 
 which part failed. it only looks simple for the most basic 
 case, the second you need to do rollbacks or really anything 
 else this approach gets so much more complicated.


```
foo()
   .case(Error: return Error.failedAt(__RANGE__))
   .bar()
   .case(Error: return Error.failedAt(__RANGE__))
   .baz;
```

And sure that looks verbose, but the moment I needed more than a 
few of them I'd just add a macro for it.
May 31 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


 oh god no. it leads to horrible code. just take a look at go.


That's not the point

Some platform doesn't have EH, and some projects ban the use of EH

If you want things to make it nicer than look at Zig/Swift and 
have a mechanism to bubble things up

The point is the feature and what it allows/enable, the syntax is 
second, let's agree on the idea first
May 26 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 26 May 2023 at 15:59:54 UTC, ryuukk_ wrote:

 On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

 On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

 For example:

 - **exception handing**: why use EH when you can have your 
 function return 2 values (error and result)


 oh god no. it leads to horrible code. just take a look at go.


 That's not the point

 Some platform doesn't have EH, and some projects ban the use of 
 EH

 If you want things to make it nicer than look at Zig/Swift and 
 have a mechanism to bubble things up

 The point is the feature and what it allows/enable, the syntax 
 is second, let's agree on the idea first


And btw Go will improve it, they have a Go2 proposal going, so 
your point is already invalid

Odin is also another nice example of proper error handling
May 26 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/19/2023 4:43 AM, GrimMaple wrote:

 Unfortunately, big compiler changes, like mentioned above deprecation of alias 
 this,


Maybe we should un-deprecate that. I appreciate your feedback on it.


 or ImportC for that matter, weren't hidden behind a preview switch. Heck, 
 ImportC didn't even go through DIP process!


ImportC didn't go through the DIP process because it is not a D language
feature 
- it's a compiler feature!
May 20 2023
parent reply Theo <Theo gmail.com> writes:
On Saturday, 20 May 2023 at 20:32:02 UTC, Walter Bright wrote:

 ImportC didn't go through the DIP process because it is not a D 
 language feature - it's a compiler feature!


Even for the compiler, a new feature as significant as ImportC - 
that can have a profound effect on the 'use' of the language - 
should have gone through some process...at least.. before finding 
its way into the official source code respository.

Not to mention all the time and attention that has been directed 
to it as well, by so many people, including yourself, likely at 
the expense of other things. Sure, some would find the feature 
useful, I guess, but most people had to direct their attention to 
it because it just appeared and had to be dealt with.

'some kind' of approval process should have been followed (in 
relation to ImportC).

That seems self-evident to me.

I'm still bewildered why it's not self-evident to you as well.
May 21 2023
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Sunday, 21 May 2023 at 23:04:40 UTC, Theo wrote:

 'some kind' of approval process should have been followed (in 
 relation to ImportC).

 That seems self-evident to me.

 I'm still bewildered why it's not self-evident to you as well.


I think people are modelling the DIP process as a 
"democratization" of the language. This is simply not the case. 
(And thank goodness!) For instance, there would be little point 
in having Walter file a DIP, as Walter is the person who decides 
whether to accept DIPs. What's he gonna do, reject his own 
feature?

The point of a DIP (as I understand it!) is this: it used to be 
the case that people would engage on these giant pull request 
fights in order to get a feature in the language, only to be 
told, very late in the process, after months of work had already 
gone into it, that the maintainers thought the feature didn't fit 
in with their vision of D. A DIP is a way to get a sort of 
preview, or "go/no-go", on whether a PR is likely to be merged if 
you embark on developing it. The forumgoers can comment on it, 
but their comments are strictly advisory. The point of the 
community review phase is not for the community to approve or 
disapprove a feature! It is merely to bring the DIP into its best 
*technical* form, writing, style, guideline adherence etc. The 
final decision remains, as it always has, with the language 
maintainers, Walter and Atila.
May 21 2023
parent Theo <Theo gmail.com> writes:
On Monday, 22 May 2023 at 06:22:02 UTC, FeepingCreature wrote:

 I think people are modelling the DIP process as a 
 "democratization" of the language. This is simply not the case. 
 (And thank goodness!) For instance, there would be little point 
 in having Walter file a DIP, as Walter is the person who 
 decides whether to accept DIPs. What's he gonna do, reject his 
 own feature?


That's very misleading. I never suggested using the DIP for 
ImportC.

That probably would not have made sense at the time, nor now.

Given that impact ImportC would have on both the compiler, the 
broader use of ImportC, and the level of attention that both 
would subsequently require by maintainers/contributerts, it could 
have been brought up at one of their meetings, and discussed, 
instead of just appearing one day in the source tree as a PR with 
little significance, just wanting approval.

I accept that Walter holds a unique position, and I respect that 
as well.

But in the end, Walter is not the only one who has to deal with 
the addition of ImportC into the compiler, or the widespread use 
of ImportC. I think that is what he failed to contemplate at the 
time. I hope such a thing would not happen again. Of course, I 
also hope that those at these 'meetings' have come up with a way 
to ensure it doesn't happen again.
May 21 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2023 4:04 PM, Theo wrote:

 I'm still bewildered why it's not self-evident to you as well.


I've been around D long enough to know well the enormous cost of trying to
adapt 
C code to be usable from D. Much, much more than the cost of ImportC. If I'd 
realized this from the start, I would have done ImportC long ago.
May 27 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/19/2023 4:43 AM, GrimMaple wrote:

 Besides that, D suits game developemnt really well, thanks to its easily 
 controllable garbage collection and access to low level features to speed up 
 your code when necessary. And while the GC implementation is sometimes
lacking, 
 just having a GC that you can decide when to run, gives you a great coding
speed 
 advanatage over C/C++, where you would spend most of your time thinking about 
 proper memory management (shared pointers aren't proper memory management).


The GC has a surprise advantage that nobody really thought of. It enables much 
more CTFE to be done. It's hard to do meaningful CTFE without memory
allocation, 
and GC is perfectly suited to that task.
May 20 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 21/05/2023 8:33 AM, Walter Bright wrote:

 The GC has a surprise advantage that nobody really thought of. It 
 enables much more CTFE to be done. It's hard to do meaningful CTFE 
 without memory allocation, and GC is perfectly suited to that task.


It makes a lot of sense looking at it in hindsight.

The GC is just a fancy pants memory allocator after all.

So the fact that we use the "GC language extensions" in CTFE is kinda 
irrelevant. It could just as easily work with malloc + free if somebody 
wanted to implement it.
May 20 2023
next sibling parent IGotD- <nise nise.com> writes:
On Saturday, 20 May 2023 at 20:41:31 UTC, Richard (Rikki) Andrew 
Cattermole wrote:


 It makes a lot of sense looking at it in hindsight.

 The GC is just a fancy pants memory allocator after all.

 So the fact that we use the "GC language extensions" in CTFE is 
 kinda irrelevant. It could just as easily work with malloc + 
 free if somebody wanted to implement it.


Translation of Walters claim:

CTFE is much easier when you don't need to worry about life times.

A follow up question is if it would be just as easy with a GC 
based on RAII.
May 21 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2023 1:41 PM, Richard (Rikki) Andrew Cattermole wrote:

 It could just as easily work with malloc + free if somebody wanted 
 to implement it.


Nobody has yet solved that problem.
May 26 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/23 1:09 AM, Walter Bright wrote:

 On 5/20/2023 1:41 PM, Richard (Rikki) Andrew Cattermole wrote:

 It could just as easily work with malloc + free if somebody wanted to 
 implement it.


 
 Nobody has yet solved that problem.


malloc -> new
free -> noop

It's CTFE, nobody cares about memory leaks because the whole context 
will go away anyway.

We don't run the GC at CTFE either.

-Steve
May 27 2023
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 27.05.23 20:26, Steven Schveighoffer wrote:

 On 5/27/23 1:09 AM, Walter Bright wrote:

 On 5/20/2023 1:41 PM, Richard (Rikki) Andrew Cattermole wrote:

 It could just as easily work with malloc + free if somebody wanted to 
 implement it.


 Nobody has yet solved that problem.


 
 malloc -> new
 free -> noop
 
 It's CTFE, nobody cares about memory leaks because the whole context 
 will go away anyway.
 
 We don't run the GC at CTFE either.
 
 -Steve


```d
import core.stdc.stdlib;

enum p=malloc(16);
void main(){
     free(p);
}
```
May 27 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:

 It's CTFE, nobody cares about memory leaks


They do when it starts running very slow and/or runs out of memory



 because the whole context will go away anyway.


I've spent a lot of time trying to reduce its memory consumption. A lot of
temps 
are now on the stack.



 We don't run the GC at CTFE either.


Yes, we do.
May 27 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/23 5:21 PM, Walter Bright wrote:

 On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:

 It's CTFE, nobody cares about memory leaks


 
 They do when it starts running very slow and/or runs out of memory


But that's no different from today.


 

 We don't run the GC at CTFE either.


 
 Yes, we do.


We do? I at least know it's not the runtime GC that's being run. And I 
really did think we aren't running the GC *during* CTFE.

In any case, migrating `malloc` calls to `new` and ignoring `free` 
should still be fine in this case.

The thing I didn't think about is the requirement to cast a void pointer 
to another type -- the compiler would have to deal with this specially, 
or match explicitly the type of mallocs we allow.

-Steve
May 27 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/27/2023 6:40 PM, Steven Schveighoffer wrote:

 On 5/27/23 5:21 PM, Walter Bright wrote:

 On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:

 It's CTFE, nobody cares about memory leaks


 They do when it starts running very slow and/or runs out of memory


 
 But that's no different from today.


Yes, and people care about it.



 We don't run the GC at CTFE either.


 Yes, we do.


 
 We do?


Every time an allocation is made with the GC, the GC may run a collection cycle.



 In any case, migrating `malloc` calls to `new` and ignoring `free` should
still 
 be fine in this case.


That's how dmd used to operate, but people ran out of memory.
May 28 2023
next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 28 May 2023 at 07:02:53 UTC, Walter Bright wrote:

 On 5/27/2023 6:40 PM, Steven Schveighoffer w

 In any case, migrating `malloc` calls to `new` and ignoring 
 `free` should still be fine in this case.


 That's how dmd used to operate, but people ran out of memory.


I never quite liked the reasoning that leaking is fine because 
its just a batch program.

I see teardown as an important part of a program. Relying on the 
OS to do it for you will likely come back to bite you at some 
point.
May 28 2023
next sibling parent max haughton <maxhaton gmail.com> writes:
On Sunday, 28 May 2023 at 07:12:22 UTC, Sebastiaan Koppe wrote:

 On Sunday, 28 May 2023 at 07:02:53 UTC, Walter Bright wrote:

 On 5/27/2023 6:40 PM, Steven Schveighoffer w

 In any case, migrating `malloc` calls to `new` and ignoring 
 `free` should still be fine in this case.


 That's how dmd used to operate, but people ran out of memory.


 I never quite liked the reasoning that leaking is fine because 
 its just a batch program.

 I see teardown as an important part of a program. Relying on 
 the OS to do it for you will likely come back to bite you at 
 some point.


It also encourages people to write code that doesn't pay 
attention to lifetimes or dependencies within the code (e.g. dmd 
was written with the assumption that you never have to free 
anything -> the code keeps references to stuff everywhere -> GC 
can't free it)
May 28 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 28 May 2023 at 07:12:22 UTC, Sebastiaan Koppe wrote:

 I never quite liked the reasoning that leaking is fine because 
 its just a batch program.

 I see teardown as an important part of a program. Relying on 
 the OS to do it for you will likely come back to bite you at 
 some point.


+1

Not having deterministic teadown of resources is a bit unnerving. 
I was never a big fan of the undeterministic deconstructors in D 
compared to the more deterministic in C++.

Not solving lifetimes in CTFE is likely to limit its versatility. 
This also include proper freeing of resourced in CTFE. For 
example if you write to a file and do not close the file in CTFE, 
what happens?
May 28 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2023 10:09 AM, IGotD- wrote:

 Not having deterministic teadown of resources is a bit unnerving. I was never
a 
 big fan of the undeterministic deconstructors in D compared to the more 
 deterministic in C++.


Struct destructors in D are equally deterministic as in C++.


 Not solving lifetimes in CTFE is likely to limit its versatility. This also 
 include proper freeing of resourced in CTFE.


A GC makes CTFE more versatile, not less.


 For example if you write to a file
 and do not close the file in CTFE, what happens?


CTFE (deliberately) does not allow access to the operating system, including 
file I/O. Jonathan Blow's Jai language does, for comparison.
May 28 2023
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/23 3:02 AM, Walter Bright wrote:

 On 5/27/2023 6:40 PM, Steven Schveighoffer wrote:

 On 5/27/23 5:21 PM, Walter Bright wrote:

 On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:

 It's CTFE, nobody cares about memory leaks


 They do when it starts running very slow and/or runs out of memory


 But that's no different from today.


 
 Yes, and people care about it.


So using the GC isn't good enough then?


 We don't run the GC at CTFE either.


 Yes, we do.


 We do?


 
 Every time an allocation is made with the GC, the GC may run a 
 collection cycle.


During CTFE too? I mean CTFE allocates memory like crazy anyways (like 
for adding two integers), but I thought collections did not run *during* 
CTFE.

I obviously could be wrong, but I thought the interpreter's data was 
self-contained, and when it was done, then it could become garbage.


 

 In any case, migrating `malloc` calls to `new` and ignoring `free` 
 should still be fine in this case.


 
 That's how dmd used to operate, but people ran out of memory.
 


If malloc allocates GC memory, wouldn't the GC just take care of it?

-Steve
May 28 2023
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 28 May 2023 at 15:40:53 UTC, Steven Schveighoffer 
wrote:

 During CTFE too? I mean CTFE allocates memory like crazy 
 anyways (like for adding two integers), but I thought 
 collections did not run *during* CTFE.


I think CTFE memory is not gcmalloc'ed anymore, see dmd PR 10343, 
["Start allocating CTFE memory in a separate 
Region"](https://github.com/dlang/dmd/pull/10343)
May 28 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2023 12:11 PM, Basile B. wrote:

 I think CTFE memory is not gcmalloc'ed anymore, see dmd PR 10343, ["Start 
 allocating CTFE memory in a separate 
 Region"](https://github.com/dlang/dmd/pull/10343)


It still is not entirely successful.
May 28 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2023 8:40 AM, Steven Schveighoffer wrote:

 So using the GC isn't good enough then?


It's good enough for CTFE :-)



 Every time an allocation is made with the GC, the GC may run a collection
cycle.


 During CTFE too? I mean CTFE allocates memory like crazy anyways (like for 
 adding two integers), but I thought collections did not run *during* CTFE.


The GC may run a collection cycle anytime a GC allocation is done.



 I obviously could be wrong, but I thought the interpreter's data was 
 self-contained, and when it was done, then it could become garbage.


I tried to do that at one point, and failed, after spending a couple weeks on 
it. It's not impossible, it's just that our CTFE implementation is a rat's nest 
and defies such improvements.

I did get a lot of the allocations done on the stack, which do go away when it 
returns. But not all.



 If malloc allocates GC memory, wouldn't the GC just take care of it?


Then you might as well just use the GC instead of malloc.
May 28 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/29/23 1:18 AM, Walter Bright wrote:


 I tried to do that at one point, and failed, after spending a couple 
 weeks on it. It's not impossible, it's just that our CTFE implementation 
 is a rat's nest and defies such improvements.


It sounds like we need to revisit how CTFE is implemented. This should 
be a priority for D.


 If malloc allocates GC memory, wouldn't the GC just take care of it?


 
 Then you might as well just use the GC instead of malloc.
 


The point is to make functions that currently use malloc CTFE-able, not 
to rewrite those functions so they are CTFE-able.

It's not as easy as I have said, but I think it's still doable.

-Steve
May 29 2023
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 29 May 2023 at 18:10:08 UTC, Steven Schveighoffer 
wrote:

 On 5/29/23 1:18 AM, Walter Bright wrote:


 I tried to do that at one point, and failed, after spending a 
 couple weeks on it. It's not impossible, it's just that our 
 CTFE implementation is a rat's nest and defies such 
 improvements.


 It sounds like we need to revisit how CTFE is implemented. This 
 should be a priority for D.


 If malloc allocates GC memory, wouldn't the GC just take care 
 of it?


 
 Then you might as well just use the GC instead of malloc.
 


 The point is to make functions that currently use malloc 
 CTFE-able, not to rewrite those functions so they are CTFE-able.

 It's not as easy as I have said, but I think it's still doable.

 -Steve


That can't actually happen while malloc is being malloc.
If we can rewrite the implementation it is possible but it means 
we have to special case malloc and treat it as a built-in 
function.
May 29 2023
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/29/23 4:11 PM, Stefan Koch wrote:

 That can't actually happen while malloc is being malloc.
 If we can rewrite the implementation it is possible but it means we have 
 to special case malloc and treat it as a built-in function.


Exactly what I'm saying... malloc should be interpreted by CTFE to be a 
special call to the CTFE allocator.

-Steve
May 29 2023
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Thank you, Mike!

The notes should be part of it.

On 5/18/2023 5:30 AM, Mike Parker wrote:

 A few notes:
 
 * I've excluded Bugzilla issues that have since been closed
 * I've tried to include examples and suggestions that were provided along with 
 the points, but I have cut out some bits that were irrelevant or extraneous.
 * I've not included compliments. I wanted to focus only on things we need to 
 fix/change. But the compliments were received and much appreciated.
 * There were three pieces that I decided not to breakdown into actionable
items 
 and included in longform instead. Those are at the bottom of the document.
 * I'll probably update this list after our planning meeting tomorrow.
 
 So, the next steps related to this. Generally, we need to:
 
 * establish some high-level goals
 * go through this list to see what fits with those goals, what doesn't fit now 
 but could be done later, and what is unlikely to ever fit any goals
 * discuss additional ideas from our own wish lists (and I'll update the
document 
 with those once I have them all)
 * prioritize everything we've decided fits our current goals
 * publish categorized task lists
 * work out who among us is responsible for what
 * get things done
 
 That last one is the hard part. I'll have more to say about it when the time
comes.
May 18 2023
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 18 May 2023 at 12:30:43 UTC, Mike Parker wrote:

 


I feel like my blog post must have been mutilated a bit since I 
see only 1/3rd of my suggestions making a list that includes 
"swap to 1 indexing"

* Im on team stepouv, the only conceivable future of languages 
improving is the re-separation of data structures and algorithms 
that share a language wide interface, you get m*n solutions out 
of m+n(x3 cause overhead) lines of code. D has... 1 good data 
structure, the built-in dynamic array, aa's aren't implemented 
yet and wont be for the foreseeable future and I hate their 
interface anyway, every part of strings design needs to be 
replace, auto decoding is stupid as is defining a fundamental 
data type in one-liner to be clever. D needs data structures.

* The average person writting the algorithm code must have gotten 
some weird ideas in their head, cause a x3 over head seems like 
an under estimation for the level of complexity in the std.

* There is a bunch of simple hacks to make ranges work, but you'd 
have to know them by heart as none are in the std, not even an 
identity map or `.map!(a=>a)`

* d3 should simplify the range interface, expand the data 
structure libs drastically, include range hacks, and lower their 
standards of correctness.
May 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/19/2023 5:57 AM, monkyyy wrote:

 * Im on team stepouv, the only conceivable future of languages improving is
the 
 re-separation of data structures and algorithms that share a language wide 
 interface, you get m*n solutions out of m+n(x3 cause overhead) lines of code.
D 
 has... 1 good data structure, the built-in dynamic array, aa's aren't 
 implemented yet and wont be for the foreseeable future and I hate their 
 interface anyway, every part of strings design needs to be replace, auto 
 decoding is stupid as is defining a fundamental data type in one-liner to be 
 clever. D needs data structures.


Autodecoding is a feature of the library, not the language. We've all agreed 
that Phobos v2 will not have it.



 * The average person writting the algorithm code must have gotten some weird 
 ideas in their head, cause a x3 over head seems like an under estimation for
the 
 level of complexity in the std.
 
 * There is a bunch of simple hacks to make ranges work, but you'd have to know 
 them by heart as none are in the std, not even an identity map or `.map!(a=>a)`
 
 * d3 should simplify the range interface, expand the data structure libs 
 drastically, include range hacks, and lower their standards of correctness.


I don't really understand these proposals. Fleshing them out a bit more would
be 
helpful.
May 28 2023
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:


 Autodecoding is a feature of the library, not the language. 
 We've all agreed that Phobos v2 will not have it.


Some news on that point? The lasts info that I remember was 
Andrei trying to find a way to conflate sources between v1 and v2 
(instead of copy/past sources), but there was a showstopper that 
I don't remember with templates or mixin or whatever ...

/P
May 28 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2023 2:39 AM, Paolo Invernizzi wrote:

 Some news on that point?


The update is nobody has been willing to invest the time into it.
May 28 2023
parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 29 May 2023 at 05:20:24 UTC, Walter Bright wrote:

 On 5/28/2023 2:39 AM, Paolo Invernizzi wrote:

 Some news on that point?


 The update is nobody has been willing to invest the time into 
 it.


Sorry, that's not right. The status, as I understand it, is that 
stdV2 was not opened for people to invest their time in it. The 
[stdV2 MR](https://github.com/dlang/phobos/pull/8309) is still 
open. I think it should get in, no matter how unfinished, in a 
way that doesn't affect stdV1. It isn't feasible to work on stdV2 
while it's base still exists only on Andrei's Phobos fork. If 
it's on Phobos codebase though, anyone can contribute as easily 
as to stable Phobos (in fact it's even easier since we don't have 
to worry about breaking V2 user code yet).

As I understand it, he complained that his PR messed up the docs 
somehow and as such could not be merged as-is.
May 29 2023
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 29 May 2023 at 13:20:22 UTC, Dukc wrote:

 Sorry, that's not right. The status, as I understand it, is 
 that stdV2 was not opened for people to invest their time in 
 it. The [stdV2 MR](https://github.com/dlang/phobos/pull/8309) 
 is still open. I think it should get in, no matter how 
 unfinished, in a way that doesn't affect stdV1. It isn't 
 feasible to work on stdV2 while it's base still exists only on 
 Andrei's Phobos fork. If it's on Phobos codebase though, anyone 
 can contribute as easily as to stable Phobos (in fact it's even 
 easier since we don't have to worry about breaking V2 user code 
 yet).


IMO the best way to make progress on stdv2 at this point is to 
create a dub package and start committing code. No need to wait 
for official approval.
May 29 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 30/05/2023 3:47 AM, Paul Backus wrote:

 IMO the best way to make progress on stdv2 at this point is to create a 
 dub package and start committing code. No need to wait for official 
 approval.


Unfortunately there are two quite big things that are more than a year 
away that it should be built from the ground up with.

- Shared library support
- Some other exception mechanism

If you start now, there will still be breaking changes to come, which 
may not be worth somebodies time to do another evaluation & partial 
rewrite for.

I'm super not looking forward to having to do this for my own stuff. 
Just the recent fixes for some DIP1000 type stuff is going to be a pain 
to go back and rewrite (although needed).

Just something to consider.
May 29 2023
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 29 May 2023 at 16:36:20 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 30/05/2023 3:47 AM, Paul Backus wrote:
 Unfortunately there are two quite big things that are more than 
 a year away that it should be built from the ground up with.

 - Shared library support
 - Some other exception mechanism

 If you start now, there will still be breaking changes to come, 
 which may not be worth somebodies time to do another evaluation 
 & partial rewrite for.


I'm not sure what it would mean for stdv2 to be built "from the 
ground up with" shared library support, especially given that 
code like ranges and algorithms will necessarily be implemented 
as templates and distributed as source code.

I agree that it's worth revisiting the use of exceptions in the 
standard library (e.g., there's a lot of code that could be 
 nogc/BetterC compatible if not for exceptions), but I don't 
think it's a good idea to sit on our hands waiting for a 
speculative language feature that may never actually materialize. 
Worst case, if and when this new mechanism lands, we can start 
work on stdv3.
May 29 2023
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:

 revisiting the use of exceptions in the standard library


As far as I'm concerned, they really shouldn't be used. I think 
exceptions are one of the worst features of C++, Java and D etc
May 29 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti via Digitalmars-d
wrote:

 On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:

 revisiting the use of exceptions in the standard library


 
 As far as I'm concerned, they really shouldn't be used. I think
 exceptions are one of the worst features of C++, Java and D etc


Care to elaborate why?


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
May 29 2023
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Monday, 29 May 2023 at 20:57:22 UTC, H. S. Teoh wrote:

 On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti 
 via Digitalmars-d wrote:

 On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:

 revisiting the use of exceptions in the standard library


 
 As far as I'm concerned, they really shouldn't be used. I 
 think exceptions are one of the worst features of C++, Java 
 and D etc


 Care to elaborate why?


 T


Mainly because exceptions are often used for errors that aren't 
really exceptional", I often found myself having to handle 
exceptions (mostly in Java and C++) that really didn't give a 
damn and just abort the program.

I have rarely seen exceptions handled well by programmers other 
than in C++ code done by really experienced programmers, I much 
prefer error handling like Rust and Go ie with multi-value 
returns, in my experience I have always found this technique 
leads to much better error handling than using exceptions. 
(https://go.dev/doc/faq#exceptions, 
https://go.dev/blog/error-handling-and-go, 
https://doc.rust-lang.org/book/ch09-00-error-handling.html)
May 29 2023
next sibling parent IGotD- <nise nise.com> writes:
On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti wrote:

 Mainly because exceptions are often used for errors that aren't 
 really exceptional", I often found myself having to handle 
 exceptions (mostly in Java and C++) that really didn't give a 
 damn and just abort the program.

 I have rarely seen exceptions handled well by programmers other 
 than in C++ code done by really experienced programmers, I much 
 prefer error handling like Rust and Go ie with multi-value 
 returns, in my experience I have always found this technique 
 leads to much better error handling than using exceptions. 
 (https://go.dev/doc/faq#exceptions, 
 https://go.dev/blog/error-handling-and-go, 
 https://doc.rust-lang.org/book/ch09-00-error-handling.html)


Interesting observation. I presume you are talking about the 
syntax of exceptions that is triggering this drawback, because 
some newer languages have exceptions like Swift but isn't really 
exceptions underneath but more Rust like return values.

I must say that I in C++ often use return values rather than 
exceptions and even return enums. Now when you write this I 
haven't really reflected on this. I just wonder why do I do this? 
I think the answer is that they are simple and stupid.

Also I seen in a professional C++ environment that programmers 
tend to use exception incorrectly. For example they tend to catch 
all exceptions even if that isn't correct as they don't handle 
all exceptions. If a specific exception isn't handled, the 
program should exit.

This doesn't mean I'm against exceptions, I think exceptions are 
a very good error handling mechanism that allow inheritance thus 
expanding on existing error structures. Rust doesn't handle this 
well I think. Swift expanded upon the error handling of Rust and 
filled this gap.

The question remains, is it the syntax or the underlying error 
handling mechanism that prevents programmers from using 
exceptions correctly?
May 29 2023
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 30/05/2023 9:18 AM, Ernesto Castellotti wrote:

 Mainly because exceptions are often used for errors that aren't really 
 exceptional", I often found myself having to handle exceptions (mostly 
 in Java and C++) that really didn't give a damn and just abort the program.


There are three categories that exceptions tend to fall into from what 
I've been able to tell.

1. Errors, show stoppers (use assert)
2. Genuinely exceptional, can stop program if not handled (use runtime 
exceptions)
3. Exceptional path ways, should not stop the program and needs to be 
handled close to throw (use value type exceptions)

A large portion of standard library stuff should really fall into the 
third, not the first or second IMO. Whereas runtime + threading should 
fall into first and second.
May 29 2023
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 30 May 2023 at 05:41:14 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 30/05/2023 9:18 AM, Ernesto Castellotti wrote:

 Mainly because exceptions are often used for errors that 
 aren't really exceptional", I often found myself having to 
 handle exceptions (mostly in Java and C++) that really didn't 
 give a damn and just abort the program.


 There are three categories that exceptions tend to fall into 
 from what I've been able to tell.

 1. Errors, show stoppers (use assert)
 2. Genuinely exceptional, can stop program if not handled (use 
 runtime exceptions)
 3. Exceptional path ways, should not stop the program and needs 
 to be handled close to throw (use value type exceptions)

 A large portion of standard library stuff should really fall 
 into the third, not the first or second IMO. Whereas runtime + 
 threading should fall into first and second.


Exception are for one thing only: bailing out of some code 
because some problem occurred that cannot be handled locally. 
That's it, really.

The whole approach where one wonders if the error is recoverable 
or not or frequent or not and whatever is just the wrong way to 
think about it. The right way is the opposite way around: if you 
find yourself frequently throwing, then your API is likely wrong, 
because you find yourself not being able to handle something 
locally that happens all the time.
May 30 2023
prev sibling parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti wrote:

 On Monday, 29 May 2023 at 20:57:22 UTC, H. S. Teoh wrote:

 On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti 
 via Digitalmars-d wrote:

 On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:

 revisiting the use of exceptions in the standard library


 
 As far as I'm concerned, they really shouldn't be used. I 
 think exceptions are one of the worst features of C++, Java 
 and D etc


 Care to elaborate why?


 T


 Mainly because exceptions are often used for errors that aren't 
 really exceptional", I often found myself having to handle 
 exceptions (mostly in Java and C++) that really didn't give a 
 damn and just abort the program.

 I have rarely seen exceptions handled well by programmers other 
 than in C++ code done by really experienced programmers, I much 
 prefer error handling like Rust and Go ie with multi-value 
 returns, in my experience I have always found this technique 
 leads to much better error handling than using exceptions. 
 (https://go.dev/doc/faq#exceptions, 
 https://go.dev/blog/error-handling-and-go, 
 https://doc.rust-lang.org/book/ch09-00-error-handling.html)


Still about the exceptions, what is the reason that motivates the 
existence of this https://dlang.org/library/object/error.html

If they are unrecoverable errors how could I handle them as 
exceptions? Print an error message and close the program? But 
then why am I using exceptions anyway to do this?
May 30 2023
parent ExceptThis <ExceptThis gmail.com> writes:
On Tuesday, 30 May 2023 at 19:45:27 UTC, Ernesto Castellotti 
wrote:

 On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti 
 wrote:

 On Monday, 29 May 2023 at 20:57:22 UTC, H. S. Teoh wrote:

 On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti 
 via Digitalmars-d wrote:

 On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:

 revisiting the use of exceptions in the standard library


 
 As far as I'm concerned, they really shouldn't be used. I 
 think exceptions are one of the worst features of C++, Java 
 and D etc


 Care to elaborate why?


 T


 Mainly because exceptions are often used for errors that 
 aren't really exceptional", I often found myself having to 
 handle exceptions (mostly in Java and C++) that really didn't 
 give a damn and just abort the program.

 I have rarely seen exceptions handled well by programmers 
 other than in C++ code done by really experienced programmers, 
 I much prefer error handling like Rust and Go ie with 
 multi-value returns, in my experience I have always found this 
 technique leads to much better error handling than using 
 exceptions. (https://go.dev/doc/faq#exceptions, 
 https://go.dev/blog/error-handling-and-go, 
 https://doc.rust-lang.org/book/ch09-00-error-handling.html)


 Still about the exceptions, what is the reason that motivates 
 the existence of this 
 https://dlang.org/library/object/error.html

 If they are unrecoverable errors how could I handle them as 
 exceptions? Print an error message and close the program? But 
 then why am I using exceptions anyway to do this?


Sadly, confusing terminology is **always** at play when 
discussing these things...

First we all need to agree that:

error != exception
Error != Exception

In my mind, a program can only produce an error, not an exception.

The word exception should only come into play when talking about 
how to handle an error - i.e see below.


(1) In essence, all programs have the potential to produce errors.

(2) These errors are either things you expect might occur, or 
things you might not expect to occur.

(3) These errors can be further classified as either being:
- errors that probably should be handled
- errors that probably should not be handled.

Often arguments over what should or shouldn't be handled are 
pointless, since it depends completely on the nature of the 
program and its intended use and audience.

For example, I would not handle an out of memory error in my 
programs. I don't expect it to occur, and if it should, I do not 
want my program to have to deal with it. Other programs may well 
need to handle it.

Whereas, I would always Try.. to handle a 'Cant save this file' 
error.

Errors that probably should be handled, should throw such errors 
as an Exception object, to be handled.

Errors that probably should not be handled, should throw such 
errors as an Error object, not to be handled.

see object.d

class Throwable : Object - The base class of all thrown objects.

class Exception : Throwable - The base class of all errors that 
are safe to catch and handle

class Error : Throwable - The base class of all unrecoverable 
runtime errors.

The great advantage of Exceptions (vs the old C like return 
values) are that Exceptions provide a robust, structured and 
uniform way in which you can handle these kinds of program errors.
May 31 2023
prev sibling parent reply A moo person <moo_mail fake.com> writes:
On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:


 Autodecoding is a feature of the library, not the language. 
 We've all agreed that Phobos v2 will not have it.


Sorry I only check in on the forums sporadically so not sure if 
this is talked about somewhere else. Can you elaborate what 
"phobos v2" entails?
Jun 19 2023
parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 20 June 2023 at 04:05:49 UTC, A moo person wrote:

 On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:


 Autodecoding is a feature of the library, not the language. 
 We've all agreed that Phobos v2 will not have it.


 Sorry I only check in on the forums sporadically so not sure if 
 this is talked about somewhere else. Can you elaborate what 
 "phobos v2" entails?


The idea of development newer versions of std.
https://forum.dlang.org/thread/slktaa$vnl$1 digitalmars.com?page=1
Jun 20 2023