Better C – A subset of D Programming Language

Post by WalterBright » Wed, Apr 29, 2020, 4:40 AM UTC

skohan wrote: post #190

kllrnohj wrote: post #185

Earlier quoted context omitted.

> However I think there are other cases where the strengths of C still add value; for instance in game development you're largely trying to do high-throughput processing over large swaths of structured data That world is dominated by C++ for the most part, though. So D's -betterC would be fighting against an incumbent that is itself also already a "better C". What value does D's -betterC bring to the table here? Skim…

I think a lot of people would argue that many C++ features, like OO, are not strictly improvements. Also C++ is a massive language, and part of the beauty of C is it's simplicity. I think what a lot of people would want is something which maintains that simplicity, but mainly delivers on basic QOL lessons we've learned in the past 40 years, like that it's nice not to have to pass around array lengths as separate vari…

Post by WalterBright » Wed, Apr 29, 2020, 4:46 AM UTC

arunc wrote: post #290

colonwqbang wrote: post #267

The chosen example (printf) doesn't make D look very good compared to C. If I modify the example to include a simple type error: printf("Hello %s", 123); Then the D version will still happily compile without warnings and will segfault. Compiling with GCC -Wall -Werror, the type error is easily caught by the compiler.

Use dmd master and you will have printf/scanf format argument validation [0]. [0] https://github.com/dlang/dmd/pull/10852

Post by WalterBright » Wed, Apr 29, 2020, 4:50 AM UTC

mhh__ wrote: post #93

kreco wrote: post #83

Earlier quoted context omitted.

I'm actually curious. until now I came across new language that sells themselves as c replacement but with a lot and lot of new features, usually "here is a new language it does a lot more than C but still compatible with it". examples in top of my head: - adding object oriented feature like built-in constructor/destructor while only default values are needed as week as a defer statement. - weird template, while I ca…

There's no such thing as a hygienic macro system if you mean textual macros. Also array type is the single biggest thing required to fix C. How many bugs in big C projects are caused by bad indexing and overruns. On top of, "oh no free features".

Post by teleforce » Wed, Apr 29, 2020, 6:19 AM UTC

Post by fluffything » Wed, Apr 29, 2020, 7:40 AM UTC

schveiguy wrote: post #187

fluffything wrote: post #116

Earlier quoted context omitted.

I'm glad that Rust has no `auto`. I find this: fn map (it: I) -> impl Iterator where I: Iterator , U: From { it.map(|t| From::from(t)) } infinitely more readable than fn map (it: I) -> auto where I: Iterator , U: From { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator `, even though the actual type cannot be named because of the anonymous closure. T…

This wouldn't work for D. D doesn't constrain return types to something less than what they are. A Range is not just an Iterator, it has optional pieces that depend completely on the given type. For example, the return of map could provide indexing, or it could provide forward and backward iteration, or it might have methods that are completely unrelated to the type. There is no good reasonable and non-confusing way…

    fn map(...) -> impl Iterator + Index

    fn map(...) -> impl Iterator + ?Index

    fn map(it: I) -> O
        where I: Iterator, U: From,
              O: impl Iterator,
              I:?Index -> O:?Index
    {
        it.map(|t| From::from(t))
    }