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, Python, C#, D, etc. C is a notable exception.

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

Scala, C#, Python all have them now.

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.

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.

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.

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.

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.

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

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.

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.

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.