Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

151–160 of 360 posts

Re: Better C – A subset of D Programming Language

#151

Earlier quoted context omitted.

Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until…

In Java, `var` comes in useful at times. For example: for (Map.Entry x : someMap) { final SomeLongType key = x.getKey(); final AnotherLongType value = x.getValue(); ... } In the above code snippet, `var x` would have been very useful because the actual type just repeats information that can be found in the next two lines. Also, usually, I'll use more speaking names instead of `key` and `value`. But if the body of the…

In java 10+

    for (Map.Entry x : someMap)    {
        final var key = x.getKey();
        final var value = x.getValue();
        ...
    }
Is valid.

Re: Better C – A subset of D Programming Language

#152
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…

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

The major examples are parts of the stdlib which offer higher-level pipelines (some answers here indicate the need for such things to be very flexible in their return values to allow this, but this is not a priori obvious - Java manages similar functionality with just the Stream class after all).

In this (and the sibling pages in algorithm) nearly every entry is listed as either "template" or "auto" relhttps://dlang.org/phobos/std_algorithm_iteration.html

Re: Better C – A subset of D Programming Language

#153
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?

Re: Better C – A subset of D Programming Language

#154
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…

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

Maybe it was fixed? I would imagine that saying in documentation that return type is auto is equivalent to not mentioning return type at all, so feels like something not intentional.

Re: Better C – A subset of D Programming Language

#155
post #34
post #14

D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.

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 different trade-offs. It's also not "assembler It's also not just C/C++/Zig/Rust/Nim/D competing at the lowest-level of the space. Ada, Forth, Scheme, and many other languages are also widely used in this space. They just aren't the "next new thing".

Re: Better C – A subset of D Programming Language

#156
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…

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

Here's one example:

https://dlang.org/phobos/std_algorithm_sorting.html#partitio...

The important line is

auto pieces = partition3(a, 4);

So, what's the type of pieces? The D standard library is written to be generic. And sure enough, that line of code will run. Where it turns into a problem is when you try to do something with it. If pieces is a range, there are certain things you can't do with it. Or maybe you can. Who knows. You'll never learn it from reading the documentation. I've been using D since 2013 and I still struggle with this at times. It's a valid complaint. (D's a great language, but is short on manpower to fix rough edges like this.)

Re: Better C – A subset of D Programming Language

#157

Earlier quoted context omitted.

> Chain of lazy computations in D often return unnamed types (so called "Voldemort" types) because finding good names for those inner structs is a challenge There is something so absurd about having "unnamed types" as an antipattern!

Not really - the concrete type isn't important, but what you can do with it is. One could argue that instead we'd use a concept in place of `auto`, and Bjarne has argued exactly that for C++.

> Not really - the concrete type isn't important, but what you can do with it is.

Then surely that's what should be shown? Rust uses `impl ` for that, the actual return type is opaque but you know it implements the specified trait.

Re: Better C – A subset of D Programming Language

#158
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…

Sometimes I feel like auto is definitely overused. In a recent fix, I changed something that returned a boolean (no templates involved) from returning auto to returning bool.

But sometimes auto is the best tool for the job, especially when writing wrapping types. In that case, yes, you have to read the documentation (and I mean what is written in the ddoc comments). But in many cases, you don't have to, because you recognize the pattern, or it's simply a wrap of the underlying type's function.

Re: Better C – A subset of D Programming Language

#159
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…

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

https://dlang.org/library/std/algorithm/iteration/map.map.ht...

    auto auto map(Range) ( 
      Range r 
    )

Re: Better C – A subset of D Programming Language

#160

Earlier quoted context omitted.

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

Here's one example: https://dlang.org/phobos/std_algorithm_sorting.html#partitio... The important line is auto pieces = partition3(a, 4); So, what's the type of pieces? The D standard library is written to be generic. And sure enough, that line of code will run. Where it turns into a problem is when you try to do something with it. If pieces is a range, there are certain things you can't do with it. Or maybe you can.…

> You'll never learn it from reading the documentation.

Did you not see the Returns section from that link?

"Returns: A std.typecons.Tuple of the three resulting ranges. These ranges are slices of the original range."

Further note: If you just saw `std.typecons.Tuple!(typeof(Range.init[0 .. $]), typeof(Range.init[0 .. $]), typeof(Range.init[0 .. $]))` which is what would have to be written there instead of auto, would that make you feel better? Do you not have to read the documentation to figure out what the function does or what actually goes into those tuples?

Post reply on HN