On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
>
> https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-ownership-borrowing/42872

Again, what are we supposed discuss in this thread? Make it a rule that OP must be clear what we are supposed to discuss. Posting a link isn't enough, there should be some kind of text that explains what OP to discuss or a question to be answered. Doing this and there is a less chance that the thread derails.

On 22.05.20 17:58, IGotD- wrote:
> On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
>>
>> https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-ownership-borrowing/42872 
>>
> 
> Again, what are we supposed discuss in this thread? Make it a rule that OP must be clear what we are supposed to discuss. Posting a link isn't enough, there should be some kind of text that explains what OP to discuss or a question to be answered. Doing this and there is a less chance that the thread derails.

There does not have to be a rail.

On 5/22/2020 12:08 AM, Araq wrote:
> [x] Users had to patch every function in order to get type safety. Check.

They didn't have to change anything. The following code compiles today on gcc:

    foo(i, j) { return i + j; }


> [x] Compiler writers had considerable effort in implementing the new standards. Check.

Nope. (Note that I speak from actual experience.) Want something that's hard to implement? See exception handling, which wasn't added.

Ya know, I've actually implemented a K+R compiler, then upgraded it to C89, then C99. You've got a very tough hill to climb trying to tell me what is hard to implement and what isn't.


> [x] New features like overloading, and type system extension like 'const' or 'restrict' were added. Check.

Overloading was not added. 'const' was added, but could be ignored, and did not result in any significant coding style change. I already discussed 'restrict' which remains unused.


> [x] New code doesn't compile with older compilers without jumping through all sort of hoops. Check.

That's true of any new feature, trivial or not.

On 5/22/2020 2:22 AM, Henrik wrote:
> do you find the ideas of the restrict keyword and VLA bad, or only the current implementation in C99?

I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right.

VLA just sucked from beginning to end.


> If the ideas are good, how would you have implemented them instead?

Restrict working requires great care on the part of the programmer to not make a mistake with it, as it is unchecked by the compiler. Which means the vast majority of users will just introduce subtle bugs when they try it. Which means no sane programmer will use it.

VLA relies far too much on the vagaries of the stack implementation. Hence it's unportable and unreliable.

C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:

https://www.digitalmars.com/articles/C-biggest-mistake.html

C89's adoption of function prototypes was a home run, but note I said adoption, not invention. They were invented by C++, and C compiler vendors (like mine) added them to C, and the committee just stamped its approval on it. C has resisted anything else that hails from C++.

On 5/22/2020 8:27 AM, Chris wrote:
> Second, Walter, I've noticed that the word "unprofessional" has become a blanket term for anything the D leadership doesn't like / want to hear. In my opinion, D has become a political enterprise.

Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.

On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
> On 5/22/2020 2:22 AM, Henrik wrote:
>> do you find the ideas of the restrict keyword and VLA bad, or only the current implementation in C99?
>
> I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right.

There's a video on YouTube Chandler Caruth about how LLVM optimises C++, one of the interesting points he made was that const is literately zero help to the compiler for optimisation.

He also said that inlining is the single most important optimisation.

On Saturday, 23 May 2020 at 09:03:38 UTC, NaN wrote:
> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>> On 5/22/2020 2:22 AM, Henrik wrote:
>>> do you find the ideas of the restrict keyword and VLA bad, or only the current implementation in C99?
>>
>> I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right.
>
> There's a video on YouTube Chandler Caruth about how LLVM optimises C++, one of the interesting points he made was that const is literately zero help to the compiler for optimisation.
>
> He also said that inlining is the single most important optimisation.

He's right about const. As for inlining LLVM loves inlining.
It's not always the right choice.
The reason why it's deemed important is because it allows the optimizer
to effectively see across function boundaries (since merging the function bodies removes that.) And it can specialize the callee code for the callers requirements.
However that can also lead to problems with code-size and therefore i-cache stalls, (the worst kind of stalls). that said, I-caches are pretty large these days to support out-of-order execution. So maybe that's less of a problem running on modern cpus.
On an embedded device you'll want to disable the inliner through (which is what -Os or Oz) does.

On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:

>
> Restrict working requires great care on the part of the programmer to not make a mistake with it, as it is unchecked by the compiler. Which means the vast majority of users will just introduce subtle bugs when they try it. Which means no sane programmer will use it.
>

Dennis Ritchie wrote a paper on why 'noalias' precursor to 'restrict' was an 'abomination'.

http://www.lysator.liu.se/c/dmr-on-noalias.html

> VLA relies far too much on the vagaries of the stack implementation. Hence it's unportable and unreliable.
>
> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>
> https://www.digitalmars.com/articles/C-biggest-mistake.html

I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.

https://www.lysator.liu.se/c/bwk-on-pascal.html

I for one am glad that C is stable and not being constantly tweaked. In part this is why it is so successful.

On Saturday, 23 May 2020 at 02:59:18 UTC, Walter Bright wrote:
> On 5/22/2020 8:27 AM, Chris wrote:
>> Second, Walter, I've noticed that the word "unprofessional" has become a blanket term for anything the D leadership doesn't like / want to hear. In my opinion, D has become a political enterprise.
>
> Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.

It'd help if the moderator also explained why a post was deleted (instead of using a blanket term like "unprofessional" which is in itself unprofessional), else it looks quite random. I think Joakim left over what he perceived as double standards in forum moderation. (Was it really worth to lose a contributor like Joakim over this?) In the old days there was practically no moderation and D wasn't the worse for it. I wonder what changed that made the leadership adopt a stricter stance on moderation. It doesn't reflect well on the D Foundation when comments by certain people (like myself) are scrutinized and deleted while some outright rude comments, attacks and even false accusations are not.

May I remind you that it was the leadership that started to treat users in a rude manner. You, Walter, answered evasively and went on to twist my words so I looked like an unreasonable fool. (One user noticed this and pointed it out to you.) This gave me the impression that you were looking down your nose at us. It hasn't escaped my attention either how Manu has been treated here (DIPs). Maybe you should ponder on this a little.

Last but not least, I think there's a growing feeling in the community that D should be rewritten as D3. Steven Schveighofer wrote a post about it. I don't understand why on earth D is not rewritten in a clean and sound manner. Take what really works, the great features that D undoubtedly has, get rid of half-baked features and all the baggage like audodecoding etc. Implement a proper ecosystem right from the start (this is of utmost importance). Why not make D great again?

Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?

On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:
> On Saturday, 23 May 2020 at 02:59:18 UTC, Walter Bright wrote:
>> On 5/22/2020 8:27 AM, Chris wrote:>> Second, Walter, I've noticed that the word "unprofessional"
>>> [...]
>>
>> Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.
>
> It'd help if the moderator also explained why a post was deleted (instead of using a blanket term like "unprofessional" which is in itself unprofessional), else it looks quite random. I think Joakim left over what he perceived as double standards in forum moderation. (Was it really worth to lose a contributor like Joakim over this?) In the old days there was practically no moderation and D wasn't the worse for it. I wonder what changed that made the leadership adopt a stricter stance on moderation. It doesn't reflect well on the D Foundation when comments by certain people (like myself) are scrutinized and deleted while some outright rude comments, attacks and even false accusations are not.
>
> May I remind you that it was the leadership that started to treat users in a rude manner. You, Walter, answered evasively and went on to twist my words so I looked like an unreasonable fool. (One user noticed this and pointed it out to you.) This gave me the impression that you were looking down your nose at us. It hasn't escaped my attention either how Manu has been treated here (DIPs). Maybe you should ponder on this a little.
>
> Last but not least, I think there's a growing feeling in the community that D should be rewritten as D3. Steven Schveighofer wrote a post about it. I don't understand why on earth D is not rewritten in a clean and sound manner. Take what really works, the great features that D undoubtedly has, get rid of half-baked features and all the baggage like audodecoding etc. Implement a proper ecosystem right from the start (this is of utmost importance). Why not make D great again?
>
> Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?

Joakim kept arguing in an increasingly petulant manner that the D conference should be canceled. He appeared to think that he had proven that it should be canceled and would not consider any notion that if enough people want to go to it, it should be held. I would guess he left because he couldn’t get his way.

I can see why you are very concerned about forum moderation as you don’t appear to use D and seem to visit the forum to solely to get perverse pleasure from degrading the language and those who work on it.