Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

121–130 of 360 posts

Re: Better C – A subset of D Programming Language

#121

Earlier quoted context omitted.

Rust is essentially C++ with auto-generated Move Constructors, and compiler errors on use-after-move, at the cost of preventing library developers from providing function overloads that eat temporaries as an optimization. So, yeah, really not a C replacement at all imo

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 an argument-eating version with the same name that is called automatically when the user gives it a temporary or specifically requests it via `std::move`. Automatically eating temporaries is very nice in the case where the caller would like to compose a bunch of "create-new-from-a-set-of-references" operations in a single expression to create one new thing from an initial set of references.

The canonical example is eliding copies in stuff like

    B*(A*x + b) + c
with overloaded * and + for vectors, since you really don't want to use something with a name other than + to request copy-elision. If you are one of those people who is grumpy about operator-overloading, you can imagine doing this with other "copy-some-refs-create-something" type functions, ... but actually you are probably grumpy about overloading those too.

Re: Better C – A subset of D Programming Language

#122

Regarding the ongoing auto/var readability issues debate, how about the popular dynamic languages that often do not even have the means of specifying a type? They surely must be suffering from huge readability issues?

Such languages (e.g. python) serve a different purpose, at least in my opinion. Using python as scripting language for small "adhoc automation" things is great.

For long-living and bigger code bases, worked on by teams, explicit types and "proper" static type system are the better choice.

E.g. it's less about readability, but maintainability.

Re: Better C – A subset of D Programming Language

#123

Earlier quoted context omitted.

I'm sorry that the question is not really related to your compilers but I'm curious about your opinion on Zig?

I know nothing about Zig.

You should definitely check Zig out. It's a relatively simple (compared to D, Rust, C++) language with C-level semantics but more modern syntax. It is designed to be extremely easy to interface with existing C source code, enabling one to convert a program from C to Zig incrementally and with minimal headaches

https://ziglang.org

Re: Better C – A subset of D Programming Language

#124
post #120

Earlier quoted context omitted.

D has functors, but it doesn't have 'Functor'. Or rather, D doesn't have concepts (of which 'Functor' is a special case); that is, the notion of a type that is characterized by having the ability to execute operations is not expressible in its typesystem. Or rather, it is, but only with classes. You want something like "a return type; fulfilling the condition of being able to be used in this way." This is not somethi…

What you're describing has names - structural types, refined types (a.k.a. contracts a.k.a. pre- and post-conditions)... It's simply a failure of D the language/compiler (and a huge anti-pattern) to not expose internal types in a way that can be displayed to the programmer.

No such internal type exists. The range interface is purely a library feature. The problem is that D has no way to include a type constraint as a part of the function type, at present. Something like out template contracts would do it probably.

Re: Better C – A subset of D Programming Language

#125

Earlier quoted context omitted.

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully made a lossy conversion for you.

If you use only explicit constructors and ban cast operators except for the most basic of types, then you have a sane language and explicitness in your code.

Sounds sensible. Google seems to agree with you. https://google.github.io/styleguide/cppguide.html#Implicit_C...

LLVM's coding standard though doesn't seem to have anything to say about implicit conversions: https://llvm.org/docs/CodingStandards.html

Re: Better C – A subset of D Programming Language

#126

Regarding the ongoing auto/var readability issues debate, how about the popular dynamic languages that often do not even have the means of specifying a type? They surely must be suffering from huge readability issues?

I find using Python libraries where the documentation doesn't tell me anything about the return type a hugely frustrating experience.

Re: Better C – A subset of D Programming Language

#128

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…

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…

A well designed language should be usable from a text editor. Even in 2020.

Re: Better C – A subset of D Programming Language

#129
post #96
post #24

Earlier quoted context omitted.

The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…

Is Range a kind of interface? If yes, then wouldn't that be the appropriate return type? edit: Looking at other answers, I think Range is probably not an interface like they exist in Java, but rather a pattern of behavior per templates in C++. Concepts are supposed to solve this problem in C++, but I don't know how well they actually do.

D's version of concepts have optional operations, it has been found to decrease the need for names

Re: Better C – A subset of D Programming Language

#130
post #18

Earlier quoted context omitted.

It's often because these functions have unnamed types. 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, they have a single use (which is to have a particular signature).

> 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 everything is worth naming, if there isn't an obvious good name for somethink (like say, a Java Anonymous Classes) then why not allow it to have no name?
Post reply on HN