www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D mentioned on Rust discussions site

reply Russel Winder <russel winder.org.uk> writes:
https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-syst=
em-for-ownership-borrowing/42872


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
May 19 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:


 Programming languages evolve or die. During early stage 
 evolution there is always experimentation. This seems fine – as 
 long as the experiments do not go into a release prior to 
 completion.


The best example of this is Java. It's evolved a lot over the 
years, in spite of being extremely heavily used and being an 
enterprise programming language. The Rust leadership would do 
well to keep in mind that evolution is not optional. Especially 
for a language that has a tiny fraction of the popularity of Java 
(in spite of the front page of Hacker News).
May 20 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2020 8:42 AM, bachmeier wrote:

 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
 

 Programming languages evolve or die. During early stage evolution there is 
 always experimentation. This seems fine – as long as the experiments do not
go 
 into a release prior to completion.


 
 The best example of this is Java. It's evolved a lot over the years, in spite
of 
 being extremely heavily used and being an enterprise programming language. The 
 Rust leadership would do well to keep in mind that evolution is not optional. 
 Especially for a language that has a tiny fraction of the popularity of Java
(in 
 spite of the front page of Hacker News).


Languages that are used over long periods of time evolve greatly after 1.0. 

exception.
May 20 2020
next sibling parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:

 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 



Before Ansi C came along, C lacked function prototypes and 
"const". I think an Ansi Standard came way later after "C version 
1.0", whatever that really was.
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 12:02 AM, Araq wrote:

 On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:

 Languages that are used over long periods of time evolve greatly after 1.0. 

 exception.


 
 Before Ansi C came along, C lacked function prototypes and "const". I think an 
 Ansi Standard came way later after "C version 1.0", whatever that really was.


I know that well. It's a glacial change compared with what has happened in
other 
languages. C version 1.0 would be K+R C, which was properly standardized in
C89, 
and handful of minor improvements came with C99.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 07:40:11 UTC, Walter Bright wrote:

 On 5/21/2020 12:02 AM, Araq wrote:

 On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:

 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 



 
 Before Ansi C came along, C lacked function prototypes and 
 "const". I think an Ansi Standard came way later after "C 
 version 1.0", whatever that really was.


 I know that well. It's a glacial change compared with what has 
 happened in other languages. C version 1.0 would be K+R C, 
 which was properly standardized in C89, and handful of minor 
 improvements came with C99.


Glacial or not, K&R C was significantly different from Ansi C, so 
C evolved after version 1 just like the other languages, features 
were added. I don't see this "notable exception". Ymmv I guess.
May 21 2020
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 21 May 2020 at 08:36:51 UTC, Araq wrote:


 improvements came with C99.


 Glacial or not, K&R C was significantly different from Ansi C, 
 so C evolved after version 1 just like the other languages, 
 features were added. I don't see this "notable exception". Ymmv 
 I guess.


"evolve greatly after 1.0"

C has not evolved "greatly". By comparison, Java is very nearly a 
different language.
May 21 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 1:36 AM, Araq wrote:

 Glacial or not, K&R C was significantly different from Ansi C, so C evolved 
 after version 1 just like the other languages, features were added. I don't
see 
 this "notable exception". Ymmv I guess.


Having implemented K+R C, C89, and C99, I know how little it actually changed.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 09:49:21 UTC, Walter Bright wrote:

 On 5/21/2020 1:36 AM, Araq wrote:

 Glacial or not, K&R C was significantly different from Ansi C, 
 so C evolved after version 1 just like the other languages, 
 features were added. I don't see this "notable exception". 
 Ymmv I guess.


 Having implemented K+R C, C89, and C99, I know how little it 
 actually changed.


Having read GCC's source code with its PROTO() macro everywhere 
to compensate for the changes, I know how much it actually 
changed. ;-)
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 2:53 AM, Araq wrote:

 Having read GCC's source code with its PROTO() macro everywhere to compensate 
 for the changes, I know how much it actually changed. ;-)


Function prototyping was a welcome, but trivial, change. I know, I went through
it.
May 21 2020
parent Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 20:19:47 UTC, Walter Bright wrote:

 On 5/21/2020 2:53 AM, Araq wrote:

 Having read GCC's source code with its PROTO() macro 
 everywhere to compensate for the changes, I know how much it 
 actually changed. ;-)


 Function prototyping was a welcome, but trivial, change. I 
 know, I went through it.


"trivial"? It affects every single function ever written in C. 
But ok, trivial. So let's compare that to the 'List' vs 
'List<String>' changes for Java's introduction of generics then. 
Hmmmm.
May 21 2020
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:

 On 5/20/2020 8:42 AM, bachmeier wrote:

 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
 

 [...]


 
 The best example of this is Java. It's evolved a lot over the 
 years, in spite of being extremely heavily used and being an 
 enterprise programming language. The Rust leadership would do 
 well to keep in mind that evolution is not optional. 
 Especially for a language that has a tiny fraction of the 
 popularity of Java (in spite of the front page of Hacker News).


 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 



ANSI C89 and then C99 changed C significantly. Some of the 
features introduced make modern C quite different from the 
initial K&R C.
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 3:57 AM, Patrick Schluter wrote:

 ANSI C89 and then C99 changed C significantly. Some of the features introduced 
 make modern C quite different from the initial K&R C.


Sorry, nope.

What C89 mostly did was clear up unspecified areas in K+R that had resulted in 
incompatible compilers. In particular, whether value-preserving or 
sign-preserving integral promotions were done. About half the compilers did it 
one way, half the other.

Value-preserving rules were selected, and the out-of-luck C compiler vendors 
were pretty graceful in accepting the changes for the greater good.

Another was clearing up confusion in how the preprocessor was supposed to work.

C99 mainly cleared up a lot of uncertainty in IEEE floating point arithmetic,
by 
stamping approval on the obvious things the C compilers were doing anyway. C99 
added a couple new features, which were badly designed and remain unused - 
things like 'restrict' and that weird way to allocate arrays on the stack. Oh, 
and those miserable trigraphs, which were never used outside of test suites.

Maybe you're talking about function prototyping. They were very welcome,
indeed, 
but they didn't make C "quite different" at all.

A "quite different" change would be something like adding modules, or getting 
rid of the preprocessor.
May 21 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:

 On 5/21/2020 3:57 AM, Patrick Schluter wrote:

 ANSI C89 and then C99 changed C significantly. Some of the 
 features introduced make modern C quite different from the 
 initial K&R C.


 Sorry, nope.

 What C89 mostly did was clear up unspecified areas in K+R that 
 had resulted in incompatible compilers. In particular, whether 
 value-preserving or sign-preserving integral promotions were 
 done. About half the compilers did it one way, half the other.

 Value-preserving rules were selected, and the out-of-luck C 
 compiler vendors were pretty graceful in accepting the changes 
 for the greater good.

 Another was clearing up confusion in how the preprocessor was 
 supposed to work.

 C99 mainly cleared up a lot of uncertainty in IEEE floating 
 point arithmetic, by stamping approval on the obvious things 
 the C compilers were doing anyway. C99 added a couple new 
 features, which were badly designed and remain unused - things 
 like 'restrict' and that weird way to allocate arrays on the 
 stack. Oh, and those miserable trigraphs, which were never used 
 outside of test suites.

 Maybe you're talking about function prototyping. They were very 
 welcome, indeed, but they didn't make C "quite different" at 
 all.

 A "quite different" change would be something like adding 
 modules, or getting rid of the preprocessor.


  As a C user I can only witness the impact on the use of the 
language not on its implementation. Some of the features 
introduced had quite the impact in the the resulting code, but 
were minimal to implement as they were already C++ features like 
the for with variable definition, variable definition anywhere.
I guarantee that if you tried to translate one of my current C 
code to an ancient compiler it would be a pain to get to work. 
Alone the preprocessor varargs would make porting to pre C99 very 
difficult endeavour.

This said, while the changes might be more conservative than to 
what happened to other languages, your statement that C hasn't 
evolved is simply false.
May 21 2020
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:



 This said, while the changes might be more conservative than to 
 what happened to other languages, your statement that C hasn't 
 evolved is simply false.


"evolve greatly"

You guys keep ignoring the adverb.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Friday, 22 May 2020 at 05:45:16 UTC, Mike Parker wrote:

 On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:



 This said, while the changes might be more conservative than 
 to what happened to other languages, your statement that C 
 hasn't evolved is simply false.


 "evolve greatly"

 You guys keep ignoring the adverb.


Because it doesn't mean anything.

[x] Users had to patch every function in order to get type 
safety. Check.
[x] Compiler writers had considerable effort in implementing the 
new standards. Check.
[x] New features like overloading, and type system extension like 
'const' or 'restrict' were added. Check.
[x] New code doesn't compile with older compilers without jumping 
through all sort of hoops. Check.

In fact, Java's backwards compatibility story looks better than 
C's to me.
May 22 2020
next sibling parent NaN <divide by.zero> writes:
On Friday, 22 May 2020 at 07:08:30 UTC, Araq wrote:

 On Friday, 22 May 2020 at 05:45:16 UTC, Mike Parker wrote:

 On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:



 This said, while the changes might be more conservative than 
 to what happened to other languages, your statement that C 
 hasn't evolved is simply false.


 "evolve greatly"

 You guys keep ignoring the adverb.


 Because it doesn't mean anything.


"C hasn't evolved" and "C hasn't evolved greatly", are absolutely 
two different statements. Walter even listed some changes 
himself, so he admits some evolution, he just doesnt view it as a 
great change.

Which at the end of the day is a subjective call. I doubt any of 
you will change each others perspective on that. Walter knows 
what changed, he doesnt view it as a big thing, writing out a 
list wont change that...
May 22 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 22 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:

 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; }


It does not compile in C99.

Old style declarations and implicit int are forbidden in C99.
May 23 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 9:30 AM, Patrick Schluter wrote:

 It does not compile in C99.
 Old style declarations and implicit int are forbidden in C99.


Ok, I had forgotten that. They still gave people 10 years to upgrade :-)
May 25 2020
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:

 On 5/22/2020 12:08 AM, Araq wrote:

 [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.


Aren't setjmp/longjmp a form of exception handling?
May 24 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2020 4:17 AM, Mark wrote:

 Aren't setjmp/longjmp a form of exception handling?


Yes, but you can do it rather simply without adding the machinery of EH.
May 25 2020
prev sibling parent Araq <rumpf_a web.de> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:

 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.


Well your C99 implementation isn't widely used and if you were to 
do it properly, you would have had to review every line of code 
in your optimizers to see if they break the new threading model 
in subtle ways. I guess you didn't do that, so C is still a 
simple language to implement when you don't try too hard and have 
few if any users.


 [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.


Overloading was added, see the _Generic keyword in C11.


 [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.


Exactly, that's the point. C isn't special.
May 26 2020
prev sibling next sibling parent Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:


 A "quite different" change would be something like adding 
 modules, or getting rid of the preprocessor.


Or adding a memory model to the language for 
parallelism/concurrency so that you need to review every line of 
code in your optimizer and see if it does a transformation that 
is now invalid... Hmmm.
May 21 2020
prev sibling parent reply Henrik <henrik nothing.com> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:

 C99 mainly cleared up a lot of uncertainty in IEEE floating 
 point arithmetic, by stamping approval on the obvious things 
 the C compilers were doing anyway. C99 added a couple new 
 features, which were badly designed and remain unused - things 
 like 'restrict' and that weird way to allocate arrays on the 
 stack. Oh, and those miserable trigraphs, which were never used 
 outside of test suites.


Hi Walter,

do you find the ideas of the restrict keyword and VLA bad, or 
only the current implementation in C99? If the ideas are good, 
how would you have implemented them instead? I'm using the latest 
version of C in my work, so your answer would be interesting to 
see.

BR, Henrik
May 22 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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++.
May 22 2020
next sibling parent reply NaN <divide by.zero> writes:
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.
May 23 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
May 23 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 2:03 AM, NaN wrote:

 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.


I discovered that myself back in the 80's. It's a huge reason why D has
immutable.
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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.
May 23 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 23 May 2020 at 13:18:38 UTC, Dibyendu Majumdar wrote:

 ...

 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.


Yeah, because it is so hard to type:

int *ptr = &my_array[0] // instead of int *ptr = my_array;


I guess the benefit is that C developers don't get RSI for their 
pointer and arrays handling code.


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


Most of those issues were sorted out by the mid-80's, also PL/I 
dialects, BLISS, Ada and Modula-2 don't suffer from them.

Ironically, NEWP, a systems programming language 10 years older 
than C, still exists and Unisys uses its security features as 
means to sell ClearPath MCP against UNIX based OSes for goverment 
level security.

Whereas those that still use C get what they deserve,

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/



https://mybuild.microsoft.com/sessions/f22a612d-0030-4e55-b389-2da0f99b8839

"Microsoft's Safe Systems Programming Languages Effort"

https://mybuild.microsoft.com/sessions/61de34c5-b111-4ece-928f-541854875862

And guess what Google is doing starting with Android 11,


 Platform hardening - We’ve expanded use of compiler-based 
 sanitizers in security-critical components, including BoundSan, 
 IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap 
 pointer tagging for apps targeting Android 11 or higher, to 
 help apps catch memory issues in production. These hardening 
 improvements may surface more repeatable/reproducible app 
 crashes in your code, so please test your apps. We've used 
 HWAsan to find and fix many memory errors in the system, and we 
 now offer HWAsan-enabled system images to help you find such 
 issues in your apps.


https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.HTML

Which is just catchin up with what iOS, Solaris SPARC and Azure 
Sphere are already doing.

So is the trust on C developer's capabilites to actually write 
memory corruption free code.
May 23 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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


The article does not support the argument. The article (section 2.1) 
discusses statically-sized arrays only, and the problem is that the size 
is part of the type; however, that's the case in C as well, as it should.

There's no doubt in my mind that the absence of a universal "doped 
pointer" (pointer plus extent) built-in or standard library in C has 
caused innumerable problems. The fact that early C versions could not 
return structs by value might have contributed to that decision.
May 23 2020
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 23.05.20 19:08, Andrei Alexandrescu wrote:

 On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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


 
 The article does not support the argument. The article (section 2.1) 
 discusses statically-sized arrays only, and the problem is that the size 
 is part of the type; however, that's the case in C as well, as it should.
 
 There's no doubt in my mind that the absence of a universal "doped 
 pointer" (pointer plus extent) built-in or standard library in C has 
 caused innumerable problems. The fact that early C versions could not 
 return structs by value might have contributed to that decision.


I think they also considered it wasteful because lengths would often be 
stored multiple times, for example if you have multiple arrays of the 
same length or otherwise related lengths.

Fixed-size arrays where the length is part of the type can actually work 
well, the type system just has to be a little less naive. This is what I 
do in my research programming languages.

For example, the following merge sort code uses fixed-size arrays, where 
the sizes are run-time values:

def merge[a:*](less: a×a→𝔹)[n:ℕ,m:ℕ](xs: a^n, ys: a^m): a^(n+m){
     (i, j) := (0, 0);
     r := []: a[];
     while i<n ∧ j<m{
         if less(xs[i], ys[j]){
             r ~= [xs[i]];
             i += 1;
         }else{
             r ~= [ys[j]];
             j += 1;
         }
     }
     return r ~ xs[i..n] ~ ys[j..m] coerce a^(n+m);
}
def sort[a:*](less: a×a→𝔹)[n:ℕ](xs: a^n): a^n{
     if n<=1{ return xs; }
     rec := sort(less);
     return merge(less)(rec(xs[0..n div 2]), rec(xs[n div 2..n]));
}
May 23 2020
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/23/20 11:46 AM, Timon Gehr wrote:> On 23.05.20 19:08, Andrei 
Alexandrescu wrote:


 There's no doubt in my mind that the absence of a universal "doped
 pointer" (pointer plus extent) built-in or standard library in C has
 caused innumerable problems. The fact that early C versions could not
 return structs by value might have contributed to that decision.


 I think they also considered it wasteful


I doubt it.


 because lengths would often be
 stored multiple times, for example if you have multiple arrays of the
 same length or otherwise related lengths.


It is understandable that there are cases where the cost of that length 
variable is measurable:

* Multiple arrays,
* Having the same length,
* and they are so short that the extra length is costly

Well, then the language has other facilities to deal with it.

Ali
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu 
wrote:

 On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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.
 


 There's no doubt in my mind that the absence of a universal 
 "doped pointer" (pointer plus extent) built-in or standard 
 library in C has caused innumerable problems. The fact that 
 early C versions could not return structs by value might have 
 contributed to that decision.


A doped pointer or hidden length would not be in the spirit of C.

I would agree that the standard library could have been better 
designed but that is a different problem.

C was designed as a replacement for assembly - not another high 
level language.  Of course C is unsafe for general purpose 
programming - it wasn't designed for that. C treats memory as a 
blob to be manipulated - types are there to help you do that more 
easily but that is all they do.
May 23 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 23 May 2020 at 20:11:17 UTC, Dibyendu Majumdar wrote:

 On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu 
 wrote:

 On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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.
 


 There's no doubt in my mind that the absence of a universal 
 "doped pointer" (pointer plus extent) built-in or standard 
 library in C has caused innumerable problems. The fact that 
 early C versions could not return structs by value might have 
 contributed to that decision.


 A doped pointer or hidden length would not be in the spirit of 
 C.

 I would agree that the standard library could have been better 
 designed but that is a different problem.

 C was designed as a replacement for assembly - not another high 
 level language.  Of course C is unsafe for general purpose 
 programming - it wasn't designed for that. C treats memory as a 
 blob to be manipulated - types are there to help you do that 
 more easily but that is all they do.


BCPL as C's percusor (given B) was never intended to be a general 
purpose systems programming language, rather as its name implies, 
for Bootstraing CPL.

As many things in computing it just got misused beyond its 
original purpose.

C designers had 10 years of high level systems programming 
languages, going back to ESPOL and NEWP at Burroughs, followed by 
PL/I, the PL/S and PL.8 at IBM, and BLISS at VAX, to get 
themselves inspired, assuming access to the respective papers or 
publications, which a place like Bells Labs certainly would 
provide in some form.
May 23 2020
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/20 4:11 PM, Dibyendu Majumdar wrote:

 On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu wrote:

 On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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.


 There's no doubt in my mind that the absence of a universal "doped 
 pointer" (pointer plus extent) built-in or standard library in C has 
 caused innumerable problems. The fact that early C versions could not 
 return structs by value might have contributed to that decision.


 
 A doped pointer or hidden length would not be in the spirit of C.


It would be in plain sight, the point being it's associated with the 
pointer. Right now there's a cottage industry of analysis tools figuring 
out which size parameter matches which pointer parameter.

This "no fat pointers" decision cascaded into another disastruous choice 
- zero terminated strings. Worse than even autodecoding :o).
May 23 2020
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 4:50 PM, Andrei Alexandrescu wrote:

 This "no fat pointers" decision cascaded into another disastruous choice -
zero 
 terminated strings. Worse than even autodecoding :o).


Ironically, a lot of C's speed advantage is lost in endlessly scanning strings 
to find their length.
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 23 May 2020 at 23:50:55 UTC, Andrei Alexandrescu 
wrote:

 On 5/23/20 4:11 PM, Dibyendu Majumdar wrote:

 On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu 
 wrote:

 On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:

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

 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.




 A doped pointer or hidden length would not be in the spirit of 
 C.


 It would be in plain sight, the point being it's associated 
 with the pointer. Right now there's a cottage industry of 
 analysis tools figuring out which size parameter matches which 
 pointer parameter.

 This "no fat pointers" decision cascaded into another 
 disastruous choice - zero terminated strings. Worse than even 
 autodecoding :o).


I think it is a fallacy to think having fat pointers would solve 
anything. As I mentioned in my previous post in C there isn't a 
strong relationship between types and memory. Types are a 
convenience for manipulating memory - a piece of memory can be 
recast to any type at any time. You need a fundamentally 
different model - and that was already solved by Java in 1995.

http://www.stroustrup.com/1995_Java_whitepaper.pdf

In 1993 Dennis Ritchie said following about C arrays:

C's solution to this has real problems, and people who are 
complaining about safety definitely have a point. Nevertheless, 
C's approach has in fact lasted, and actually does work. ... You 
can't take the pure language and use it, for example, as a system 
programming language. It needs other things.

What's interesting is that in 2020 we still do not have a viable 
replacement for C. Why?

Because C's choices are necessary choices for a systems 
programming language.
If that wasn't the case everyone would just be writing programs 


The real problem in my view is that people use C/C++ to write 
code they should not.
May 24 2020
next sibling parent reply Les De Ridder <les lesderid.net> writes:
On Sunday, 24 May 2020 at 09:29:23 UTC, Dibyendu Majumdar wrote:

 [...]

 What's interesting is that in 2020 we still do not have a 
 viable replacement for C. Why?


C++ and D(asBetterC) are viable replacements in my experience. C++
explicitly has design goals like 'Leave no room for a lower level
language' and the zero-overhead principle. These generally apply 
to
DasBetterC too.

Many would also argue that Rust and some newer languages like Zig 
fit
the bill too.
May 24 2020
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:

 C++ and D(asBetterC) are viable replacements in my experience. 
 C++
 explicitly has design goals like 'Leave no room for a lower 
 level
 language' and the zero-overhead principle. These generally 
 apply to
 DasBetterC too.

 Many would also argue that Rust and some newer languages like 
 Zig fit
 the bill too.


Well the jury is still out on these. Until we see a real OS 
written in Rust or D or Zig - he proof is not in claims but in 
the doing.
May 24 2020
next sibling parent reply The Holy Drinker <the holy.drinker> writes:
On Sunday, 24 May 2020 at 11:08:42 UTC, Dibyendu Majumdar wrote:

 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:

 C++ and D(asBetterC) are viable replacements in my experience. 
 C++
 explicitly has design goals like 'Leave no room for a lower 
 level
 language' and the zero-overhead principle. These generally 
 apply to
 DasBetterC too.

 Many would also argue that Rust and some newer languages like 
 Zig fit
 the bill too.


 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but in 
 the doing.


I haven't used it, but here's an OS written in Rust, 
https://www.redox-os.org/. Zig will probably be used to write 
one, too. I wish I could say the same for D, but the former two 
languages have mind-share, and developers are enthused by them.
May 24 2020
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 24 May 2020 at 16:05:38 UTC, The Holy Drinker wrote:

 I haven't used it, but here's an OS written in Rust, 
 https://www.redox-os.org/. Zig will probably be used to write 
 one, too. I wish I could say the same for D, but the former two 
 languages have mind-share, and developers are enthused by them.


There is a kernel written in D:

https://github.com/PowerNex/PowerNex
May 24 2020
parent reply The Holy Drinker <the holy.drinker> writes:
On Sunday, 24 May 2020 at 17:49:02 UTC, Meta wrote:

 On Sunday, 24 May 2020 at 16:05:38 UTC, The Holy Drinker wrote:

 I haven't used it, but here's an OS written in Rust, 
 https://www.redox-os.org/. Zig will probably be used to write 
 one, too. I wish I could say the same for D, but the former 
 two languages have mind-share, and developers are enthused by 
 them.


 There is a kernel written in D:

 https://github.com/PowerNex/PowerNex


Yes, but it's nowhere near where redox is at, and I doubt it ever 
will be in such a place. Plus, Rust is much younger than D, and 
it already has an OS that's actively developed and fairly along. 
Such is life.
May 24 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 24 May 2020 at 23:22:42 UTC, The Holy Drinker wrote:

 Yes, but it's nowhere near where redox is at, and I doubt it 
 ever will be in such a place. Plus, Rust is much younger than 
 D, and it already has an OS that's actively developed and 
 fairly along. Such is life.


I think the powernex thing started off as a fork of one of my 
little toys I was doing 2012ish - D is quite excellent for the 
task, was back then and even better now - but the task is also 
basically a waste of time.

It is something you do because you have time to kill so it favors 
the young.
May 24 2020
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:

 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:

 C++ and D(asBetterC) are viable replacements in my experience. C++
 explicitly has design goals like 'Leave no room for a lower level
 language' and the zero-overhead principle. These generally apply to
 DasBetterC too.

 Many would also argue that Rust and some newer languages like Zig fit
 the bill too.


 
 Well the jury is still out on these. Until we see a real OS written in 
 Rust or D or Zig - he proof is not in claims but in the doing.


It would be wasteful to write an OS to prove the claims. Unless there is 
a technical impossibility, then it's doable.

Let's do it the other way: What proof there is for the claim that those 
languages cannot be used for writing OSes? I know D enough to know that 
it can be used to manage a CPU, send electrical signals to all the I/O 
devices around it, etc.

Ali
May 25 2020
next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:

 On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:



 
 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but in 
 the doing.


 It would be wasteful to write an OS to prove the claims. Unless 
 there is a technical impossibility, then it's doable.


Of course that would be silly. My assumption is that someone will 
write an OS in one of these languages because of security 
concerns. I think Google is looking at using Rust in Fuchsia. 
Fuchsia is interesting because the kernel was initially in C, but 
now I believe mostly it is in C++ to gain additional type safety.

https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md


 Let's do it the other way: What proof there is for the claim 
 that those languages cannot be used for writing OSes? I know D 
 enough to know that it can be used to manage a CPU, send 
 electrical signals to all the I/O devices around it, etc.


Well there are several things to consider.

First is memory safety - I believe the only way to write OS in D 
or Rust is to use unsafe constructs in parts. Arguably this can 
be done in C++ too - mostly use smart pointers for example, and 
make restricted use of unsafe code.

Secondly a real world OS that is used can tell us if truly the 
resulting OS was more secure than say Linux which is written in 
C. Right now there are theoretical claims that the OS will be 
more secure.

In case of Rust there is an additional question - can development 
scale? Rust is particularly hard programming language in my view. 
Writing simple linked list or tree structure is not a trivial 
task in Rust. So can it scale to thousands of developers?

Finally performance impact of safe code. One of the reasons why 
folks use unsafe practices is that it is most performant.

I am not suggesting that D cannot be used to write an OS, but it 
remains to be seen whether an OS written in D or Rust is actually 
more secure in the real world.
May 25 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:

 On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:

 On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:



 
 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but 
 in the doing.


 It would be wasteful to write an OS to prove the claims. 
 Unless there is a technical impossibility, then it's doable.


 Of course that would be silly. My assumption is that someone 
 will write an OS in one of these languages because of security 
 concerns. I think Google is looking at using Rust in Fuchsia. 
 Fuchsia is interesting because the kernel was initially in C, 
 but now I believe mostly it is in C++ to gain additional type 
 safety.

 https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md


 Let's do it the other way: What proof there is for the claim 
 that those languages cannot be used for writing OSes? I know D 
 enough to know that it can be used to manage a CPU, send 
 electrical signals to all the I/O devices around it, etc.


 Well there are several things to consider.

 First is memory safety - I believe the only way to write OS in 
 D or Rust is to use unsafe constructs in parts. Arguably this 
 can be done in C++ too - mostly use smart pointers for example, 
 and make restricted use of unsafe code.

 Secondly a real world OS that is used can tell us if truly the 
 resulting OS was more secure than say Linux which is written in 
 C. Right now there are theoretical claims that the OS will be 
 more secure.



That one is easy, IBM i and IBM z/OS are written in a mix of 
Assembly and PL/S. Modern versions now also include C++, but it 
wasn't there during their first 20 years.

Unisys ClearCase MCP, written in NEWP, an almost safe systems 
programming language, 10 years older than C, the OS doesn't do 
Assembly, all CPU low level features are exposed as compiler 
intrisics.

Was one of the first OSes to introduce the concept of unsafe code 
already during the 60's, any executable or library with unsafe 
code is tainted and requires admin being signed off by the admin 
for execution.

Unisys still keeps it around and sells it to governments and 
business that need three letter agency security level access for 
data processing.

Common to all of them, C is only used on the POSIX containers.
May 25 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:

 First is memory safety - I believe the only way to write OS in 
 D or Rust is to use unsafe constructs in parts. Arguably this 
 can be done in C++ too - mostly use smart pointers for example, 
 and make restricted use of unsafe code.


Memory management in OS development is special and differs a lot 
from writing normal applications. In C++, you usually don't use 
STL at all because it is usually configured for some other 
operating system and will not compile at all. Just including 
std::shared_ptr will include a lot of other things and 
compilation will fail. Second, there are hidden allocations in 
the STL containers and you don't want those when writing 
operating systems. With operating systems you want to control 
every allocation in order to minimize memory use and 
fragmentation. Linux is full of "smart pointers" ie. reference 
counting but they are done manually. Same would be in C++, 
reference counting is done manually. You want to minimize the 
increase/decrease of counters in such environment, something you 
might not care that much about in applications.

There are other things that you avoid in C++, like std::function 
that has hidden allocations. Operating systems developers usually 
make a special library that is tailored for such development. 
Also forget about exceptions and RTTI.

Right now C++ seems to be the best fit for operating system 
development. Extra safety like bounds checking in D is a good 
thing but the full feature set of C++ still out-competes D as you 
have to use betterC.

The memory safety in for example Rust is just in the way when 
writing operating systems. You have to resort to so many tricks 
outside the safe language that it is more or less useless. Also 
Rust is a highly annoying language when it comes many classical 
data structures. D is in a middle spot here but lacks features 
like full polymorphism in betterC which still makes C++ a better 
choice.
May 25 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 13:04:42 UTC, IGotD- wrote:

 On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:

 First is memory safety - I believe the only way to write OS in 
 D or Rust is to use unsafe constructs in parts. Arguably this 
 can be done in C++ too - mostly use smart pointers for 
 example, and make restricted use of unsafe code.


 Memory management in OS development is special and differs a 
 lot from writing normal applications. In C++, you usually don't 
 use STL at all because it is usually configured for some other 
 operating system and will not compile at all. Just including 
 std::shared_ptr will include a lot of other things and 
 compilation will fail. Second, there are hidden allocations in 
 the STL containers and you don't want those when writing 
 operating systems. With operating systems you want to control 
 every allocation in order to minimize memory use and 
 fragmentation. Linux is full of "smart pointers" ie. reference 
 counting but they are done manually. Same would be in C++, 
 reference counting is done manually. You want to minimize the 
 increase/decrease of counters in such environment, something 
 you might not care that much about in applications.

 There are other things that you avoid in C++, like 
 std::function that has hidden allocations. Operating systems 
 developers usually make a special library that is tailored for 
 such development. Also forget about exceptions and RTTI.

 Right now C++ seems to be the best fit for operating system 
 development. Extra safety like bounds checking in D is a good 
 thing but the full feature set of C++ still out-competes D as 
 you have to use betterC.

 The memory safety in for example Rust is just in the way when 
 writing operating systems. You have to resort to so many tricks 
 outside the safe language that it is more or less useless. Also 
 Rust is a highly annoying language when it comes many classical 
 data structures. D is in a middle spot here but lacks features 
 like full polymorphism in betterC which still makes C++ a 
 better choice.


Apparently people writing high integrity kernels in languages 
like Ada/SPARK don't find bounds checking a nuisance.

Which by the way, also applies to C and C++ written kernels via 
static analysis tooling validation like MISRA and AUTOSAR.
May 25 2020
parent reply welkam <wwwelkam gmail.com> writes:
On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:

 Apparently people writing high integrity kernels in languages 
 like Ada/SPARK don't find bounds checking a nuisance.


I looked at generated assembler if boundscheck=off did something 
and found that in few places that I looked it did nothing. Most 
array accesses happen in a foreach loop and compiler is smart 
enough to remove those checks. I haven't done thorough 
investigation but my guess is that array bounds checks are left 
in places where you should have checks even if you wrote that 
code in C.
May 25 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 20:30:51 UTC, welkam wrote:

 On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:

 Apparently people writing high integrity kernels in languages 
 like Ada/SPARK don't find bounds checking a nuisance.


 I looked at generated assembler if boundscheck=off did 
 something and found that in few places that I looked it did 
 nothing. Most array accesses happen in a foreach loop and 
 compiler is smart enough to remove those checks. I haven't done 
 thorough investigation but my guess is that array bounds checks 
 are left in places where you should have checks even if you 
 wrote that code in C.


Indeed, bounds checking elision has been a thing for ages in 
everything else other than C / C++ / Objective-C, and mostly when 
it doesn't work, it is considered a compiler bug that needs to be 
eventually fixed.
May 25 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 4:33 AM, Dibyendu Majumdar wrote:

 First is memory safety - I believe the only way to write OS in D or Rust is to 
 use unsafe constructs in parts.


Rust is heavily reliant on unsafe library modules to get key things done. D 
relies on that, too (hence  safe and  system code), but Rust's more restrictive 
model needs more of it.  live will, too.
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:48 AM, Ali Çehreli wrote:

 It would be wasteful to write an OS to prove the claims. Unless there is a 
 technical impossibility, then it's doable.
 
 Let's do it the other way: What proof there is for the claim that those 
 languages cannot be used for writing OSes? I know D enough to know that it can 
 be used to manage a CPU, send electrical signals to all the I/O devices around 
 it, etc.


I've written embedded systems with no operating system, and drivers for 
operating systems.

There's no technical reason why DasBetterC can't be used for this. In fact, it 
would shine at it.
May 25 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 DasBetterC


[...]

Everytime I see this, I can't help thinking it's faux-German for "*the*
better C". :-P


T

-- 
The early bird gets the worm. Moral: ewww...
May 25 2020
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/25/20 3:20 PM, H. S. Teoh wrote:

 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 DasBetterC


 [...]
 
 Everytime I see this, I can't help thinking it's faux-German for "*the*
 better C". :-P
 
 
 T
 


Walter said he noticed the same thing a few days before his DConf 2018 
presentation in Munich. :)

Ali
May 25 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/25/20 6:20 PM, H. S. Teoh wrote:

 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 DasBetterC


 [...]
 
 Everytime I see this, I can't help thinking it's faux-German for "*the*
 better C". :-P


I assumed that was the joke all along!
May 25 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 5:11 PM, Andrei Alexandrescu wrote:

 On 5/25/20 6:20 PM, H. S. Teoh wrote:

 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 DasBetterC


 [...]

 Everytime I see this, I can't help thinking it's faux-German for "*the*
 better C". :-P


 
 I assumed that was the joke all along!


I couldn't have come up with a better pun in 50 years. This one was quite by 
fortuitous accident.
May 25 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 3:20 PM, H. S. Teoh wrote:

 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 DasBetterC


 [...]
 
 Everytime I see this, I can't help thinking it's faux-German for "*the*
 better C". :-P


It is. It came about because I actually wrote "D as Better C" and did a double
take!
May 25 2020
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 25 May 2020 at 22:20:04 UTC, H. S. Teoh wrote:

 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via 
 Digitalmars-d wrote: [...]

 DasBetterC


 [...]

 Everytime I see this, I can't help thinking it's faux-German 
 for "*the* better C". :-P


 T


Yes the very first time I read it, I read it as Das Better C. It 
should come with a blinkenlights module.
May 26 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 24 May 2020 at 11:08:42 UTC, Dibyendu Majumdar wrote:

 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:

 C++ and D(asBetterC) are viable replacements in my experience. 
 C++
 explicitly has design goals like 'Leave no room for a lower 
 level
 language' and the zero-overhead principle. These generally 
 apply to
 DasBetterC too.

 Many would also argue that Rust and some newer languages like 
 Zig fit
 the bill too.


 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but in 
 the doing.


The improvements that Microsoft has been doing to .NET out of 
their Midori and .NET Native experience, alongside their recent 
announcement at BUILD 2020 for first class support for Rust on 
Windows, alongside Amazon, Oracle, Apple and Google's ongoing 
adoption on their OS and cloud platforms, kind of prove the point 
for me.

I occasionally still come over here due to the community, and 
less so about D.
May 25 2020
prev sibling parent ag0aep6g <anonymous example.com> writes:
On 24.05.20 11:29, Dibyendu Majumdar wrote:

 Types are a convenience for manipulating memory - a piece of memory can 
 be recast to any type at any time.


That's not true with strict aliasing.
May 24 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 6:18 AM, Dibyendu Majumdar wrote:

 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.


The amount of buffer overflows enabled by it is legendary.
May 23 2020
prev sibling parent mw <mingwu gmail.com> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:

 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 



Speaking of language evolution, when D can get string 
interpolation in? it's great help in debug print.

https://forum.dlang.org/post/jtlogapmndsezrjvylaw forum.dlang.org
May 21 2020
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:


 Who wants to use an "ongoing experiment" to write real world 
 software? That's to invite disaster. And worse than an 
 "experiment" that might have a sound scientific basis, D keeps 
 adding stuff at whim because others have it too, like 
 children. I wonder why D hasn't gained the traction its users 
 think it should have. Hm. There's a lot more to programming 
 and PLs than fancy ideas. A certain rigidity and 
 straight-lacedness is often the result of a lot of (creative) 
 thinking and experimentation that takes place before a PL 
 reaches 1.0 - not afterwards.


 Programming languages evolve or die. During early stage 
 evolution there is always experimentation. This seems fine – as 
 long as the experiments do not go into a release prior to 
 completion.


Evolve yes. And yes, Java was too conservative for too long until 
Kotlin came along. But there's a difference between a language 
evolving when there's a need to evolve (changes in hardware, 
networking, big data, new platforms or even changes in 
programming culture (you know, the whole lot), and the erratic 
addition of the latest fancy features, i.e. when the language 
becomes a playground for hackers and nerds, forever chaotic and 
immature.

 Mike Parker
Finally, dear Mike Parker, since you have deleted my original 
reply to Russel, may I ask you to delete any answer that quotes 
my answer, else your censorship looks a bit inconsistent. But 
consistency is apparently not held in highly regarded here 
anyway, given your statement from the 19 October 2019:

"I also don't want to be deleting negative posts just because 
they're negative. Then we get into the business of deleting 
replies that quote them, and maybe even losing some actual useful 
signal in all the noise."

Here's the full statement: 
https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org

If it wasn't you, Mike, who took down my answer, please remind 
that person of your statement on Forum Moderation.

Anyway, as soon as people have to revert to censorship (it's not 
the first time here either) they have something to hide. 
Greatness speaks for itself.
May 20 2020
next sibling parent Just Another D Programmer <ja d.p> writes:
On Wednesday, 20 May 2020 at 17:49:49 UTC, Chris wrote:

 "I also don't want to be deleting negative posts just because 
 they're negative. Then we get into the business of deleting 
 replies that quote them, and maybe even losing some actual 
 useful signal in all the noise."

 Here's the full statement: 
 https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org

 If it wasn't you, Mike, who took down my answer, please remind 
 that person of your statement on Forum Moderation.

 Anyway, as soon as people have to revert to censorship (it's 
 not the first time here either) they have something to hide. 
 Greatness speaks for itself.


I didn't catch the entirety of your reply, but I am able to read 
what Russel quoted. From those excerpts, I think the negativity 
wasn't the issue but your superfluously rude phrasing--something 
with which you seemingly have an issue. This is, of course, 
merely my opinion, and Mike can speak for himself.
May 20 2020
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
20.05.2020 20:49, Chris пишет:

 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
  
 Evolve yes. And yes, Java was too conservative for too long until Kotlin 
 came along. But there's a difference between a language evolving when 
 there's a need to evolve (changes in hardware, networking, big data, new 
 platforms or even changes in programming culture (you know, the whole 
 lot), and the erratic addition of the latest fancy features, i.e. when 
 the language becomes a playground for hackers and nerds, forever chaotic 
 and immature.
 
  Mike Parker
 Finally, dear Mike Parker, since you have deleted my original reply to 
 Russel, may I ask you to delete any answer that quotes my answer, else 
 your censorship looks a bit inconsistent. But consistency is apparently 
 not held in highly regarded here anyway, given your statement from the 
 19 October 2019:
 
 "I also don't want to be deleting negative posts just because they're 
 negative. Then we get into the business of deleting replies that quote 
 them, and maybe even losing some actual useful signal in all the noise."
 
 Here's the full statement: 
 https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org
 
 If it wasn't you, Mike, who took down my answer, please remind that 
 person of your statement on Forum Moderation.
 
 Anyway, as soon as people have to revert to censorship (it's not the 
 first time here either) they have something to hide. Greatness speaks 
 for itself.


I do not like the censorship but the last your posts I've seen are 
negative plus do not contain useful information for community. If you 
disappointed in D that is a normal thing, just go ahead, take another PL 
and leave us. Please, do not repeat to us that you think we were/are 
wrong. But if you want to return - welcome back!
May 20 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2020 10:49 AM, Chris wrote:

 Finally, dear Mike Parker, since you have deleted my original reply to Russel, 
 may I ask you to delete any answer that quotes my answer, else your censorship 
 looks a bit inconsistent. But consistency is apparently not held in highly 
 regarded here anyway, given your statement from the 19 October 2019:



That post can be justifiably removed for unprofessional demeanor in belittling 
others. Continue doing so, and they'll be removed, too.

Mike has my full support and his decisions are final.
May 20 2020
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 20 May 2020 at 21:26:40 UTC, Walter Bright wrote:

 On 5/20/2020 10:49 AM, Chris wrote:

 Finally, dear Mike Parker, since you have deleted my original 
 reply to Russel, may I ask you to delete any answer that 
 quotes my answer, else your censorship looks a bit 
 inconsistent. But consistency is apparently not held in highly 
 regarded here anyway, given your statement from the 19 October 
 2019:



 That post can be justifiably removed for unprofessional 
 demeanor in belittling others. Continue doing so, and they'll 
 be removed, too.

 Mike has my full support and his decisions are final.


First of all, thanks Mike Parker for also deleting Russel's 
answer that contained my original answer (I still wonder how that 
could escape you). It looks a lot better now, more consistent. 
Well done.

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.

Thirdly, is there an update of the companies that use D? How many 
really use it, do the companies listed still use D (what about 
sociomantic?) and what do they use it for? Facebook is listed, I 
remember Andrei did some stuff (including a script like program), 
are they still using it actively?
May 22 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 22 May 2020 at 15:27:13 UTC, Chris wrote:

Just in case, I'd like to have an answer to this:

Is there an update of the companies that use D? How many really 
use it, do the companies listed still use D (what about 
sociomantic?) and what do they use it for? Facebook is listed, I 
remember Andrei did some stuff (including a script like program), 
are they still using it actively?
May 22 2020
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/22/20 8:28 AM, Chris wrote:> On Friday, 22 May 2020 at 15:27:13 
UTC, Chris wrote:

 Just in case, I'd like to have an answer to this:

 Is there an update of the companies that use D? How many really use it,
 do the companies listed still use D (what about sociomantic?) and what
 do they use it for? Facebook is listed, I remember Andrei did some stuff
 (including a script like program), are they still using it actively?


Unless the users are as excited as I am to present at conferences how 
they benefit from D, nobody can answer those questions. Open source does 
not work that way. Even if one asked Sociomantic or Facebook, they are 
not obliged to give answers.

Ali
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 09:00:03 UTC, Ali Çehreli wrote:


 Unless the users are as excited as I am to present at 
 conferences how they benefit from D, nobody can answer those 
 questions. Open source does not work that way. Even if one 
 asked Sociomantic or Facebook, they are not obliged to give 
 answers.

 Ali


Fair enough, but I think it would make sense to contact those 
companies. I'm sure Facebook would be willing to give you an 
answer like "We are still using it actively." However, if you 
list Facebook on your homepage and _if_ it's only because Andrei 
once wrote some stuff (because he actually worked there), that 
looks a bit weird, exaggerated, not optimal. Imagine somebody 
finds out that your claims are inflated, they might get very 
angry.

By the way, you're probably one of the people to ask this 
question. Are there annual financial reports of the D Language 
Foundation? How the money was spent etc.?
May 25 2020
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 22 May 2020 at 15:27:13 UTC, Chris wrote:


 First of all, thanks Mike Parker for also deleting Russel's 
 answer that contained my original answer (I still wonder how 
 that could escape you). It looks a lot better now, more 
 consistent. Well done.


Either I completely overlooked it or Russel uses a newsreader and 
had already downloaded the post before I deleted it but replied 
after. Our policy is to delete posts that quote deleted posts.


 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.


I have to disagree with this. Forum moderation is not censorship 
and there's nothing political behind it. I deleted your post not 
because of the opinion you expressed, but because of the manner 
in which you expressed it. You have a habit of insulting the 
people who put their time and energy into this project. Your 
posts have in the past derailed and disrupted otherwise civil 
discussions. I would not have deleted your post if you had not 
included that insult, or it if were a one-off. But for you, it's 
a pattern. And I will delete any future posts if you can't 
refrain from insulting people. You can be critical and civil at 
the same time. Please try to do so going forward.
May 22 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 22 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
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?
May 23 2020
next sibling parent reply Tony <tonytdominguez aol.com> writes:
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.
May 23 2020
next sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 15:18:51 UTC, Tony wrote:

 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.


"petulant", interesting.


 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.


Well, this shows you the flexible standards that are applied 
here. Your comment is unprofessional, it belittles others and 
makes assumptions about other people's motives. Very well, I'm 
not a snowflake, but in the name of consistency may I ask Mike 
Parker to remove Tony's comment. It fulfills the criteria that 
make a comment eligible for deletion according to Mike Parker's 
and Walter Bright's own definition. Anything else would be 
inconsistent and reek of double standards (and people will notice 
it sooner or later).
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 8:18 AM, Tony wrote:

 seem to visit the forum to solely to get perverse pleasure from 
 degrading the language and those who work on it.


We expect professional decorum at all times toward all forum members.
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:57:47 UTC, Walter Bright wrote:

 On 5/23/2020 8:18 AM, Tony wrote:

 seem to visit the forum to solely to get perverse pleasure 
 from degrading the language and those who work on it.


 We expect professional decorum at all times toward all forum 
 members.


Then please delete his post [1] just as you deleted others that 
you deemed "unprofessional", for consistency's and credibility's 
sake. Else it looks like two standards are being applied, one to 
critics of D (deletion), others to its proponents/defenders (slap 
on the wrist).

[1] 
https://forum.dlang.org/post/dnvcsbzrzeboxucmejdm forum.dlang.org
May 26 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:


 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?


Again, we aren't deleting criticism. If we were, 90% of your 
posts would have hit the bin by now. I repeat myself: criticism 
is welcome, the denigration of community members is not.
May 23 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:

 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:


 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?


 Again, we aren't deleting criticism. If we were, 90% of your 
 posts would have hit the bin by now. I repeat myself: criticism 
 is welcome, the denigration of community members is not.


And I should add that if we weren't using a web interface to a 
newsgroup server, we would most likely have better moderation 
tools. We'd be able to edit posts. But all we can do is delete 
them.
May 23 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 23 May 2020 at 16:03:13 UTC, Mike Parker wrote:

 And I should add that if we weren't using a web interface to a 
 newsgroup server, we would most likely have better moderation 
 tools. We'd be able to edit posts. But all we can do is delete 
 them.


There's really no technical reason why you can't do that now, 
just editing the server database.

People with a local copy will still see the old one, of course, 
but that's just like how mailing list users like me don't see any 
deletion actions either.
May 23 2020
next sibling parent Johnny <jo h.nny> writes:
On Saturday, 23 May 2020 at 16:11:30 UTC, Adam D. Ruppe wrote:

 There's really no technical reason why you can't do that now, 
 just editing the server database.

 People with a local copy will still see the old one, of course, 
 but that's just like how mailing list users like me don't see 
 any deletion actions either.


Yeah, mod logs and notifications of mod actions are all possible, 
but like everything, someone needs to step up and implement them.
May 23 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 9:11 AM, Adam D. Ruppe wrote:

 There's really no technical reason why you can't do that now, just editing the 
 server database.


We can indeed do that, but editing posts made by others opens up a terrible can 
of worms. So if any part of a post is unacceptable, we chose to delete the 
entire post.
May 23 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:

 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:


 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?


 Again, we aren't deleting criticism. If we were, 90% of your 
 posts would have hit the bin by now. I repeat myself: criticism 
 is welcome, the denigration of community members is not.


90%? Where's the proof? You shouldn't make exact statements like 
that based on an estimate.
May 25 2020
parent NaN <divide by.zero> writes:
On Monday, 25 May 2020 at 08:25:30 UTC, Chris wrote:

 On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:

 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:


 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?


 Again, we aren't deleting criticism. If we were, 90% of your 
 posts would have hit the bin by now. I repeat myself: 
 criticism is welcome, the denigration of community members is 
 not.


 90%? Where's the proof? You shouldn't make exact statements 
 like that based on an estimate.


Dont feed the troll.
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 7:33 AM, Chris wrote:

 Deleting criticism is certainly not the right approach and will come back to 
 bite you.


We don't delete criticism of D. We delete rudeness towards other forum members.

We also neither edit posts nor delete parts of posts. If it contains rudeness 
towards others, the whole thing gets removed, along with any replies that quote
it.

Therefore, if you do not want your criticisms of D deleted, do not package it 
with rudeness towards other forum members.

Joakim is welcome to return anytime he wants, and we've told him that.
May 23 2020
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:

 Joakim is welcome to return anytime he wants, and we've told 
 him that.


So you forgive him? Great!
May 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:28 AM, Chris wrote:

 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:

 Joakim is welcome to return anytime he wants, and we've told him that.


 
 So you forgive him? Great!


We didn't ask him to leave. We only required that he conform to the forum
rules. 
Anyone is welcome here if they comport themselves in a professional manner.
May 25 2020
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:47:36 UTC, Walter Bright wrote:

 On 5/25/2020 1:28 AM, Chris wrote:

 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:

 Joakim is welcome to return anytime he wants, and we've told 
 him that.


 
 So you forgive him? Great!


 We didn't ask him to leave. We only required that he conform to 
 the forum rules. Anyone is welcome here if they comport 
 themselves in a professional manner.


That's not the point. The point was that you treated him in a way 
that made him lose faith in D and its leadership. There was 
stonewalling and censorship which sounds familiar to me. My point 
was that by treating him in this way, you lost a contributor to 
and a proponent of D. Was it really worth it? I get the 
impression that you don't really regret it, so somehow you must 
think it was worth it, for what reason, I don't know.
May 26 2020
next sibling parent NaN <divide by.zero> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:

 On Monday, 25 May 2020 at 20:47:36 UTC, Walter Bright wrote:

 On 5/25/2020 1:28 AM, Chris wrote:

 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:






Dont feed the troll.
May 26 2020
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:

 On Monday, 25 May 2020 at 20:47:36 That's not the point. The 
 point was that you treated him in a way that made him lose 
 faith in D and its leadership. There was stonewalling and 
 censorship which sounds familiar to me.


Walter deleted one of Joakim's posts (and the subsequent thread) 
for a gratuitous insult. Joakim claimed his post was deleted for 
criticizing DConf, despite the fact that all of hos other posts 
criticizing DConf were still online. He and I had an email 
discussion about this and he refused to accrpt it.

It's unfortunate that some people can't understand the difference 
between modrration and censorship, but if they insist on that 
position there's nothiing we can do about it.

Now, if you wish to discuss this topic further, please start a 
new thread. It's gone way off topic for this thread.
May 26 2020
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:

 That's not the point. The point was that you treated him in a 
 way that made him lose faith in D and its leadership. There was 
 stonewalling and censorship which sounds familiar to me. My 
 point was that by treating him in this way, you lost a 
 contributor to and a proponent of D. Was it really worth it? I 
 get the impression that you don't really regret it, so somehow 
 you must think it was worth it, for what reason, I don't know.


Hm, what the point is, then? The first thought is that in your 
opinion is that the languge maintainers should more clearly admit 
some mistakes you think they have made.

But that can't be everything. If you were simply fed up with the 
langauge and it's leadership, you would just leave. There are 
thousands of screwed up projects at the Internet, and they are 
simply abandoned. What is it that is holding you here arguing for 
the sinking ship (as that is what D is judging by your posts)?
May 26 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
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.


May I ask you to remove this comment then:

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

Secondly, again you do not answer a single question or address 
any of the issues raised. This pattern stared to emerge around 
2017 I think. Instead of addressing issues raised the manner in 
which they are raised is more important. So an inconvenient 
comment / question is either labelled as "unprofessional" or 
"unspecific". In this way you don't need to address the issue. 
Hm, politicians do that when they have no substantial arguments, 
engineers shouldn't behave like that. So once again:

1. Is the list of companies that use D up to date? What is D 
mainly used for or is it still being used actively? E.g. 
Facebook, do they still use it?

2. Will there be some sort of D3 that incorporates all the great 
features and drops the dead weight? It would actually be a good 
monument of your life's work.
May 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:23 AM, Chris wrote:

 Secondly, again you do not answer a single question or address any of the
issues 
 raised. This pattern stared to emerge around 2017 I think. Instead of
addressing 
 issues raised the manner in which they are raised is more important. So an 
 inconvenient comment / question is either labelled as "unprofessional" or 
 "unspecific". In this way you don't need to address the issue. Hm, politicians 
 do that when they have no substantial arguments, engineers shouldn't behave
like 
 that. So once again:


You're not getting a response as long as you keep asking questions in a rude
manner.
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:53:46 UTC, Walter Bright wrote:

 On 5/25/2020 1:23 AM, Chris wrote:

 Secondly, again you do not answer a single question or address 
 any of the issues raised. This pattern stared to emerge around 
 2017 I think. Instead of addressing issues raised the manner 
 in which they are raised is more important. So an inconvenient 
 comment / question is either labelled as "unprofessional" or 
 "unspecific". In this way you don't need to address the issue. 
 Hm, politicians do that when they have no substantial 
 arguments, engineers shouldn't behave like that. So once again:


 You're not getting a response as long as you keep asking 
 questions in a rude manner.


How exactly were the questions asked in a "rude" manner?

Anyway, here they are again:

1. Is there an update of the companies that (still) use D (cf. 
sociomantic)?
2. Is Facebook still actively developing software in D?
3. Are there plans for a D3 that will contain all / most of the 
good features and drop the dead weight / errors?
4. Are there annual financial statements of the D Language 
Foundation that can be accessed by the public/users/community?
May 26 2020
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 20.05.20 16:14, Russel Winder wrote:

 On Wed, 2020-05-20 at 10:07 +0000, Chris via Digitalmars-d 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


    [gheli]
 "It is inspired by Rust's borrow checker, but it fails in
 comparison to it. It provides very little guarantees and does not
 prioritize safety. It is being adding (IMO) simply as a PR stunt
 as the current implementation stands." > One of the Rust illuminati complained
about this comment, asking 




people to

 respect others' work. The point was well made and seems to have attracted a
 lot of support.
 


It is a bit weird that anyone would sign up for the Rust forums for the 
sole purpose of making a non-PC comment about D. :)

The reaction to the above comment was predictable but I don't think it 
was necessary. ZiCog's subsequent comment was just as dismissive but it 
was phrased using nice words so he did not get a wrist slap. Basically 
it's just a translation of the comment to PC speak. "I prefer to think 
of it this way."

Personally I prefer the atmosphere of the D forums -- generally 
respectful and professional, but being respectful is not subordinate to 
being able to make technical points, passionate debate is allowed and 
you don't have to spend time deciphering criticism that is disguised as 
a compliment or wondering whether your point has been taken.
May 20 2020
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-05-20 at 22:10 +0200, Timon Gehr via Digitalmars-d wrote:

=20


[=E2=80=A6]

 Personally I prefer the atmosphere of the D forums -- generally=20
 respectful and professional, but being respectful is not subordinate to=


=20

 being able to make technical points, passionate debate is allowed and=20
 you don't have to spend time deciphering criticism that is disguised as=


=20

 a compliment or wondering whether your point has been taken.


The Rust forum is generally very good, very positive, even when discussing
crufty bits of Rust =E2=80=93 of which there are many, just like any other =
programming
language. The posts being dissected in this thread here is very unusual and
hence the interjection of the Rust illuminati to stop the disrespectful
negative vibes.

I think that D got a mention in the Rust forum is overall very good. It's j=
ust
sad the person used disrespectful tones. It happens in all language specifi=
c
milieu though, due I would suggest to tribalism, to try and protect the les=
s
confident members from a potential threat to the tribe's canon.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
May 21 2020
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 21 May 2020 at 09:09:27 UTC, Russel Winder wrote:

 The Rust forum is generally very good, very positive, even when 
 discussing crufty bits of Rust – of which there are many, just 
 like any other programming language. The posts being dissected 
 in this thread here is very unusual and hence the interjection 
 of the Rust illuminati to stop the disrespectful negative vibes.

 I think that D got a mention in the Rust forum is overall very 
 good. It's just sad the person used disrespectful tones. It 
 happens in all language specific milieu though, due I would 
 suggest to tribalism, to try and protect the less confident 
 members from a potential threat to the tribe's canon.


I think you missed Timons point. He talked about the reaction to 
the dismissive comments, not dismissive comments themselves. 
Here, I have never seen a moderator to drop in as quickly as he 
did in Rust forums. I think Timon meant that he prefers our 
higher tolerance of negativity. And I agree with him.
May 21 2020
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 20 May 2020 at 20:10:27 UTC, Timon Gehr wrote:

 Personally I prefer the atmosphere of the D forums -- generally 
 respectful and professional, but being respectful is not 
 subordinate to being able to make technical points, passionate 
 debate is allowed and you don't have to spend time deciphering 
 criticism that is disguised as a compliment or wondering 
 whether your point has been taken.


I've never seen folks on the Rust forums shy away from detailed 
debate of technical points.

I do get that it's not nice to feel there are people looking over 
your shoulder policing your tone, but in general, all the rules 
come down to is "don't be a [TECHNICAL TERM]".  Which isn't 
_that_ hard, and is something we all ought to aim for.

At the end of the day we're in a lucky position, because our 
community is smaller and closer-knit, that we can get away 
without much moderation.  Rust's forum rules are an inevitable 
consequence of growth, and to a degree some of their growth may 
have been made easier because they pro-actively enforced 
standards of community behaviour from early on.
May 21 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 21.05.20 14:14, Joseph Rushton Wakeling wrote:

 On Wednesday, 20 May 2020 at 20:10:27 UTC, Timon Gehr wrote:

 Personally I prefer the atmosphere of the D forums -- generally 
 respectful and professional, but being respectful is not subordinate 
 to being able to make technical points, passionate debate is allowed 
 and you don't have to spend time deciphering criticism that is 
 disguised as a compliment or wondering whether your point has been taken.


 
 I've never seen folks on the Rust forums shy away from detailed debate 
 of technical points.
 ...


My expectation would be that technical points are ignored or deleted if 
someone feels they are are phrased the wrong way. I might be wrong, but 
currently I have no desire to post on the Rust forums as it does not 
appear to be welcoming to all perspectives.


 I do get that it's not nice to feel there are people looking over your 
 shoulder policing your tone, but in general, all the rules come down to 
 is "don't be a [TECHNICAL TERM]".  Which isn't _that_ hard, and is 
 something we all ought to aim for.


There is a difference between a rule being something to strive for and 
being something that makes sense to enforce formally, especially based 
on a very vague formalization that everyone agrees with (but nobody 
agrees with anyone else on what it means).

Arguably, the moderator is being a [TECHNICAL TERM]. I think it's 
ridiculous to reprimand someone for calling a change log entry a "PR 
stunt", especially if you are not even interested enough in the subject 
matter to have an opinion on whether it's true or not and therefore add 
nothing of substance to the topic at hand. I doubt that this opinion 
would be welcome on the Rust forums.


 At the end of the day we're in a lucky position, because our community 
 is smaller and closer-knit, that we can get away without much 
 moderation.


I.e., we respect each other more, therefore we don't get offended so easily.


 Rust's forum rules are an inevitable consequence of growth, 
 and to a degree some of their growth may have been made easier because 
 they pro-actively enforced standards of community behaviour from early on.


The enforcement is necessarily superficial, inconsistent, biased and 
will tend to be overzealous. Anyway, I don't claim my opinion on this is 
universal or shared by the majority. It's possible that this is a 
contributor to Rust's popularity. Maybe upvoting generic moderation 
comments feels nice to some people. (It's the comment with the largest 
number of hearts in the thread even though it is essentially without 
merit and completely off-topic.)
May 21 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:


 Maybe upvoting generic moderation comments feels nice to some 
 people. (It's the comment with the largest number of hearts in 
 the thread even though it is essentially without merit and 
 completely off-topic.)


Well it's easy to agree with. Without having to look for sources 
of information.
Or having to go through the trouble of validating them.
May 21 2020
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:

 My expectation would be that technical points are ignored or 
 deleted if someone feels they are are phrased the wrong way.


Is that based on actual experience of this happening?  Best not 
to assume without evidence.


 I might be wrong, but currently I have no desire to post on the 
 Rust forums as it does not appear to be welcoming to all 
 perspectives.


It's worth pointing out that their forum FAQ explicitly 
discourages responding to a post's tone rather than to its 
content.  Which does rather suggest that actually they want 
people to _overlook_ phrasing and focus on the technical points.


 There is a difference between a rule being something to strive 
 for and being something that makes sense to enforce formally, 
 especially based on a very vague formalization that everyone 
 agrees with (but nobody agrees with anyone else on what it 
 means).


Where's the formal enforcement in this case?  Unless I missed 
something, a moderator merely offered advice as to how to achieve 
a more constructive discussion.


 At the end of the day we're in a lucky position, because our 
 community is smaller and closer-knit, that we can get away 
 without much moderation.


 I.e., we respect each other more, therefore we don't get 
 offended so easily.


Rather, that we _know_ each other better, and so are less likely 
to misinterpret each other or assume bad faith.  People seem to 
get offended here reasonably often, even so :-)


 The enforcement is necessarily superficial, inconsistent, 
 biased and will tend to be overzealous. Anyway, I don't claim 
 my opinion on this is universal or shared by the majority. It's 
 possible that this is a contributor to Rust's popularity. Maybe 
 upvoting generic moderation comments feels nice to some people. 
 (It's the comment with the largest number of hearts in the 
 thread even though it is essentially without merit and 
 completely off-topic.)


I'm not sure I see what was superficial, inconsistent, or biased 
about this particular intervention: unsubstantiated accusations 
of bad faith are generally toxic to good discussion and I don't 
see the problem in reminding people of that.

Odds are that would happen in this community too, it's just more 
likely to be a regular member of the community that does the 
reminding, rather than someone with formal moderator 
responsibilities.

No community scales without having some measure of enforcement of 
expected standards of behaviour.  And while I might not 
necessarily draw the line where the Rust forums do, it doesn't 
seem like a particularly egregious line, all things considered, 
to step in to remind people to be constructive, assume good 
faith, and keep on topic.
May 21 2020
parent welkam <wwwelkam gmail.com> writes:
On Thursday, 21 May 2020 at 20:10:06 UTC, Joseph Rushton Wakeling 
wrote:

 unsubstantiated accusations of bad faith are generally toxic to 
 good discussion


This reminded me of this. Watch it until ~14 min for relevant 
part.
https://youtu.be/soYkEqDp760?t=621

I think we all have seen here how one person with one comment 
just derails the conversation and we get increased hostility 
towards each other. Because of this I think moderation is a 
necessary evil but it requires great wisdom to draw lines 
correctly.
May 21 2020
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:

 My expectation would be that technical points are ignored or 
 deleted if someone feels they are are phrased the wrong way. I 
 might be wrong, but currently I have no desire to post on the 
 Rust forums as it does not appear to be welcoming to all 
 perspectives.


FWIW I do feel that the mods are being a tad heavy-handed in 
trying to push people to not widen the discussion to broader 
language comparisons.  I might feel differently if there were 
more people actually discussing the OB feature in-depth, but in 
such a short thread, with so few participants, it seems 
unnecessarily intrusive.

Still, it remains advice only so far.  If I get a ban or a 
timeout I may feel obliged to invite you to say "I told you so" 
... :-)
May 22 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.05.20 15:29, Joseph Rushton Wakeling wrote:

 On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:

 My expectation would be that technical points are ignored or deleted 
 if someone feels they are are phrased the wrong way. I might be wrong, 
 but currently I have no desire to post on the Rust forums as it does 
 not appear to be welcoming to all perspectives.


 
 FWIW I do feel that the mods are being a tad heavy-handed in trying to 
 push people to not widen the discussion to broader language 
 comparisons.  I might feel differently if there were more people 
 actually discussing the OB feature in-depth, but in such a short thread, 
 with so few participants, it seems unnecessarily intrusive.
 
 Still, it remains advice only so far.  If I get a ban or a timeout I may 
 feel obliged to invite you to say "I told you so" ... :-)


Which is why they don't want to do that and instead prefer if you comply 
based on the latent threat of it happening. :P

Also, the tone is getting more stern, arguably getting close to or 
crossing the line of what they would consider acceptable for 
participants in the actual discussion. Fewer hearts now, too.
May 22 2020
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 22 May 2020 at 15:48:04 UTC, Timon Gehr wrote:

 Which is why they don't want to do that and instead prefer if 
 you comply based on the latent threat of it happening. :P


Yes.  Which is partly why I took the decision to tweak the 
dragon's tail by arguing that our "off-topic" was actually 
relevant :-P


 Also, the tone is getting more stern, arguably getting close to 
 or crossing the line of what they would consider acceptable for 
 participants in the actual discussion. Fewer hearts now, too.


Indeed.
May 23 2020
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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


There is a technical question I'd like to ask here.

One of the participants in that thread posted what I considered 
to be a rather contrived example where `malloc`, `free`, and 
casts from pointer to value types and back (!) were combined to 
produce a use-after-free effect.

Of course it's trivial to find ways to get the compiler to catch 
the casts as unsafe.  But in trying this out I settled on a much 
simpler formulation that still doesn't get caught as a violation 
of ` live` rules:

```
 live int* test1()
{
     import core.stdc.stdlib : free, malloc;
     import std.stdio : writefln;

     scope p = cast(int*) malloc(int.sizeof);

     free(p);

     writefln!"%d"(*p);

     return p;
}
```

Now, I'm not making any judgement here -- this is a provisional 
feature with many limitations, that is clearly intended as a 
first step to something bigger, and which is clearly advertised 
as having a _lot_ of bugs right now.  But I would like to 
understand, for my own sake, why the above example is not 
detecting that it's invalid to dereference `p` for the `writeln`, 
or indeed to return `p` from the function.

(Tried with a freshly built dmd 2.092.0.)
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 2:26 PM, Joseph Rushton Wakeling wrote:

 (Tried with a freshly built dmd 2.092.0.)


Because it's a bug I fixed fairly recently. Not sure if it's been pulled yet. 
Anyhow, my version of dmd produces:

    live int* test1()
   {
     import core.stdc.stdlib : free, malloc;
     import core.stdc.stdio;

     scope p = cast(int*) malloc(int.sizeof);

     free(p);

     printf("%d\n",*p); // variable `p` has undefined state and cannot be read

     return p; // variable `p` has undefined state and cannot be read
               // variable `p` is returned but is Undefined
  }

The error messages aren't the greatest, but they are accurate.
May 21 2020
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 22 May 2020 at 02:04:19 UTC, Walter Bright wrote:

 Because it's a bug I fixed fairly recently.


Ah, all good then.  So just wait for 2.092.1? :-)
May 22 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
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.
May 22 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
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-owner
hip-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.
May 22 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, May 23, 2020 at 09:05:47PM -0700, Walter Bright via Digitalmars-d wrote:

 On 5/23/2020 6:18 AM, Dibyendu Majumdar wrote:

 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.


 
 The amount of buffer overflows enabled by it is legendary.


On Sat, May 23, 2020 at 09:15:18PM -0700, Walter Bright via Digitalmars-d wrote:

 On 5/23/2020 4:50 PM, Andrei Alexandrescu wrote:

 This "no fat pointers" decision cascaded into another disastruous
 choice - zero terminated strings. Worse than even autodecoding :o).


 
 Ironically, a lot of C's speed advantage is lost in endlessly scanning
 strings to find their length.


Hear, hear.

Having worked for the past 25 years in the industry primarily with C
code, I have to say that the amount of C code with hidden potential
buffer overflows is staggering. In spite of a big push in the past 10 or
so years towards safer C coding practices, I still regularly come across
code that have potential buffer overflows hidden deep within a large
codebase, and code being freshly written that *still* depend on
unfounded assumptions about array length -- because manually passing the
length is just too cumbersome, and people either don't bother with it,
or make mistakes while doing it (nothing like passing the wrong length
to screw up your day -- esp. when it gets missed by QA and proceeds to
explode in the customer's production environment -- or worse, it
*doesn't* get noticed by the customer until a hacker decides to exploit
it).

Not to mention the gigantic pain in writing said code in C in the first
place -- you constantly have to be burning mental calories trying to
keep track of which pointer goes with which length, making sure to
manually check bounds, making sure to think thrice about your loop to
prevent overruns, endless calls to strlen() without even thinking about
the performance consequences. I'm serious, I work with a huge codebase
of almost 2 million LOC, and strlen calls are everywhere, including
inside macros that nobody really takes the time to understand but just
sprinkle everywhere in their code.  The complexity of managing all of
this is just beyond any normal person's capacity given the tight
deadlines we have to meet, so people just call strlen willy-nilly
without even thinking about the performance consequences.  And of
course, the huge bulk of code that expects null-terminated strings means
it's just not worth trying to encapsulate the length in any sort of way
-- you make yourself incompatible with just about everything else, and
end up spending endless effort converting to/from char* instead, which
is not any better.  So the problem perpetuates itself, and becomes an
accumulated cost that nobody can feasibly improve without rewriting the
entire darned thing from ground up. (And even then, all it takes is for
*someone* to start using char* again, and suddenly you're back to square
one. No sane C coder uses anything *but* char* for strings in "normal"
C code. Esp. code that needs to talk to other C libraries not written by
your team. It's inextricably ingrained in C culture.)

And strlen isn't even the end of it; because of manual memory
management, everyone defensively strdup's every darned string that they
intend to keep, because there's just no other sane way of ensuring the
pointer won't get invalidated later (and no guarantee, thanks to default
mutability, that someone won't change the contents of the string down
the line and screw up the assumptions in your code). So in addition to
strlen, your average typical C code is plagued with endless calls to
strdup or equivalent, even for simple things like taking substrings.

Some people complain about D strings being immutable(char)[], but I tell
you, encapsulated in that seemingly-trivial construct is a ton of
experience-backed insight about string management in C-like programming
paradigms that's worth careful study.  People like bashing D because of
the GC, but nobody talks about how *not* needing to call strlen() or
strdup() endlessly is such a performance booster, not to mention it
makes your code a LOT simpler and your APIs a lot cleaner to work with.

Considering just how much work has been poured into mitigating the
horrible consequences of "no fat pointers" and null-terminated strings
-- think about how much effort has been poured into dealing with buffer
overflow bugs over the past 10 years: entire cottage industries have
grown up around developing tools for detecting and fixing these sorts of
things, and who knows how much money poured into cleaning up the
consequences of the countless security exploits enabled by said buffer
overflows -- the laughable "benefits" of saving a couple of bytes by
using only lean pointers hardly measures up to anything less than a
colossal design mistake in retrospect. If you can even call them
"benefits": think of all the costly workarounds people have had to put
up with: everyone inventing their own way of passing array length
instead of having a standardized API, and inevitably doing it poorly /
with costly slip-ups, and the memory cost of needing to invent, store,
and manage data structures needed to manage all of this -- I surmise
this in itself already counteracts any meager savings one may have
gained by avoiding fat pointers. (Just think: in any persistent struct
that carries pointers to arrays: you're already paying for the cost of a
fat pointer because you need to store the length somehow anyway, except
everyone invents their own way of doing this so you're essentially
already paying for fat pointers but with none of the benefits of having
a standardized fat pointer type that's been tested to do it correctly:
you run the risk of human error at every turn.)

D arrays being fat pointers is a HUGE step at getting rid of the
nonsensical churn C's array-pointers lead to. And immutable(char)[] is a
huge saver in terms of performance.  The two taken together is one of
D's strengths.


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but haven't
gotten around to it yet. " -- swr
May 23 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
You should write this up and post it on Reddit / Hackernews!
May 24 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 24, 2020 at 06:02:53PM -0700, Walter Bright via Digitalmars-d wrote:

 You should write this up and post it on Reddit / Hackernews!


Feel free to copy-n-paste it, you have my full permission.  I'm done
with Reddit and have no interest in investing in another timesink like
Hackernews.  I have too much on my hands and not enough time to do it.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
May 24 2020
prev sibling parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Sunday, 24 May 2020 at 06:08:42 UTC, H. S. Teoh wrote:

 On Sat, May 23, 2020 at 09:05:47PM -0700, Walter Bright via 
 Digitalmars-d wrote:

 [...]


 On Sat, May 23, 2020 at 09:15:18PM -0700, Walter Bright via 
 Digitalmars-d wrote:

 [...]


 [...]


I totally agree with this. I am teaching low-level courses like 
assembly language and operating systems and I have to tell you 
most of the students (even top students) have a lot of problems 
implementing data structures correctly in C. Almost all of them 
make mistakes with regards to null-terminated strings, arrays and 
pointers. That is mostly because they are focused on implementing 
the actual algorithm/solution and they do not care about the rest 
of the details. If a veteran programmer sometimes accidentally 
introduces a buffer overflow bug, imagine how it is for a young 
programmer that is eager to focus on interesting problems and 
doesn't care about boring stuff like making sure the length of 
the array is correct.

We are talking about students that will get hired in 1-2 years 
and most likely it will take a while before they actually 
understand the importance of paying attention to this sort of 
issues; in the mean time they will recklessly introduce 
vulnerabilities all over the place. Having an automatic method of 
verification is the best solution to this sort of problem. 
Languages have evolved enough so that we should not concern 
ourselves with such low-level details.
May 25 2020