Better C – A subset of D Programming Language

Post by Koshkin » Tue, Apr 28, 2020, 3:48 PM UTC

stevefan1999 wrote: post #153

F-0X wrote: post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

Well, not everyone likes automatic type deduction -- some people just like to torment him/herself by repeating information that is unneeded. Why?

Post by oconnor663 » Tue, Apr 28, 2020, 3:50 PM UTC

neutronicus wrote: post #121

oconnor663 wrote: post #102

Earlier quoted context omitted.

I'm not super familiar with r-value references, but doesn't passing-by-value in Rust do essentially the same thing as that optimization does in C++?

Yes. But this is all a bit uglier at the call site, since either the library provides value-semantically-similar things with different names that either eat their arguments or copy-from-reference them, provides only the argument-eating version and relies on the caller to `clone` at their discretion, or provides only the referencing version and fails to elide copies. In C++ you can provide a referencing version, and a…

    fn eats_a_string(s: impl Into) {
        dbg!(s.into());
    }

    fn main() {
        eats_a_string("foo");
        eats_a_string("foo".to_string());
        eats_a_string(&"foo".to_string());
    }

Post by pjmlp » Tue, Apr 28, 2020, 3:55 PM UTC

fluffything wrote: post #155

skohan wrote: post #34

Earlier quoted context omitted.

Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…

Many programmers think of the programming world as: "assembly When I see someone saying that they prefer D/Nim/Zig value proposition as a "better C" than Rust, what I see is that people are just starting to realize that there are many more options than C for doing programming tasks that require a more precise interaction with the hardware. It's just not "assembly", but there are multiple different assemblers with dif…

Post by Koshkin » Tue, Apr 28, 2020, 4:00 PM UTC

jfkebwjsbx wrote: post #108

MaxBarraclough wrote: post #20

Earlier quoted context omitted.

In the interests of perpetuating this endless flamewar, here's Herb Sutter saying C++ programmers should use auto 'by default'. (I see my snarky comment there got no reply.) https://softwareengineering.stackexchange.com/a/180616/

Herb Sutter is biased. He works on C++ language lawyering, he works on new features, he works in the STL, etc. People like him tend to be biased about using auto because they write mostly libraries and generic ones at that (data structures, for instance). In most code out there you actively avoid templates if possible, so that code is concrete, compiles faster and is easier to debug.

Post by Koshkin » Tue, Apr 28, 2020, 4:03 PM UTC

benibela wrote: post #169

kqr wrote: post #35

This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.

I use Pascal as better C