Better C – A subset of D Programming Language
dlang.org
dlang.org
And that's a huge shame. Because in general I really liked using D.
pragma(msg, T);
(I see my snarky comment there got no reply.)
Like Sutter's answer, this point doesn't answer the complaint. People on the anti-auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto, they're asking for an answer to their readability problem.
Perhaps IDEs could infer types and display them as a superscript. That would keep just about everyone happy. (Perhaps not Vim users.)
LLVM's coding standard though doesn't seem to have anything to say about implicit conversions: https://llvm.org/docs/CodingStandards.html
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.
There is something so absurd about having "unnamed types" as an antipattern!
But the reason why it seems that types without names are absurd is that types are only real for the interpreter or compiler. At runtime they aren't used anymore. So it's absurd that a construct made for humans to understand and describe code starts to become something opaque to human understanding because they're impossible to be named.
Then surely that's what should be shown? Rust uses `impl <Trait>` for that, the actual return type is opaque but you know it implements the specified trait.
I am not sure what to make of this pattern. At least the documentation should be more explicit about these Voldemort types. Documentation has other issues as well. The standard documentation generator doesn't cope well with version statements (conditional compilation), potentially skipping docs for stuff that wouldn't be compiled into a particular build variant.
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.
Maybe D should allow the user to name the return type (an existential variable) and static assert stuff on it:
`SomeVar f(…) with isRange!SomeVar` or whatever. `auto` just means "you have to read the implementation because it can be literally anything"
uint startsWith(alias pred = (a, b) => a == b, Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && (Needles.length > 1) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));
fn map<U, T, F, I>(it: I) -> impl Iterator<Item=U>
where I: Iterator<Item=T>, U: From<T>
{
it.map(|t| From::from(t))
}
fn map<U, T, F, I>(it: I) -> auto
where I: Iterator<Item=T>, U: From<T>
{
it.map(|t| From::from(t))
}
The second one leaves me guessing what the return type is.
If the actual type cannot be named, it is rarely the case that this is all there is to it. Usually, users are expected to use that type "somehow" (it is a `Range`?), and that means that there are some interfaces that these types implement.
This style of coding is so bad, that it turns out the example has a syntax error. Good luck finding it without the compiler or a quality editor though. Worse, the example doesn't actually work due to further bugs.
Anyway, rust by itself may be ok. Some of the core concepts are good, but the way people are using it is leading to inpenteratble messes of code. Code like the above combined with what seems excessive/unnecessary use of generics create problems for more advanced usage when it comes to learning and modifying a piece of code. Some people have blamed this on the language's learning curve, but I'm not sure that is appropriate. By itself the language is fairly straightforward, the difficulties occur when people are working around the language and pile in masses of write only code.
That particular code block IMHO is why rust is going to have a hard time truly gaining widespread usage. Even as someone somewhat familiar with rust, moving the example into a program, and modifying it in fairly trivial ways took me the better part of a day.
Maybe this is just me misreading your phrasing, but why would you actually have to break it apart into `let` statements? You can look up the types without modifying the program. Or are you talking about asking the compiler for the types with the `let _: () = ...` (or similar) trick? At that point you can just ask an IDE, also without modifying the program.
Most code samples get automatically tested, but READMEs currently do not.
Rust does not have
fn foo() -> let { ... }
fn foo() -> let { 0_i32 }
let x: i32 = foo();
fn bar() -> let { 0_f32 }
let y: f32 = bar();
If you change the implementation of `bar` with such a feature to return `i32` instead, all calling code of `bar` would break. And that's precisely why Rust doesn't have D/C++'s `auto` in return position.
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 to describe all the things map could return depending on the input. It's much better to just describe it conceptually in the human-readable docs, and let the person understand the result.
I'll note that just above the function map in D's source is the documentation. You just need a little more context, and it will describe what map returns in a much more (IMO) useful fashion than a return type that might be several lines long and consist of various static conditionals:
"The call map!(fun)(range) returns a range of which elements are obtained by applying fun(a) left to right for all elements a in range."
This is the difference between duck typing and generics.
https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...
The D way of solving this is to statically query the properties of the passed in type at compile time whenever a part of the template needs to be specialized. It can make for very concise code, but you can't name the exact input type with this approach.
I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work, so I just gave up and wrote multiple functions without generics.
I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.
No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref
The others are separate abstract operations which are available (implemented) on vecs e.g. AsRef/AsMut denote that you can trivially get a (mutable) reference to the parameter from a vec. The implementations are similarly trivial (https://doc.rust-lang.org/src/alloc/vec.rs.html#2348-2374).
> I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.
Do you mean this one?
auto auto map(Range) (Range r)"Returns: A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun."
D’s syntax for the template body looks much more similar to normal D code, in Rust the pattern macro syntax is like a language to itself and procedural macros need a fair bit of boilerplate, including explicit “quote” blocks.
I think the main takeaway is that there are very different ways of approaching language design. In Rust there was a decision to make the function signature the single place which defines the guaranteed input and output types to a function, but that is a trade-off. It encourages a more complex type system, as the flexibility of functions is on a sense constrained by the type system. Personally I like that explicitness, since there is only one place to look. In the future features like const generics and GATs will make that more powerful.
But on the other hand, D appears to be able to support much more complex types (possibly dependent types?) by not requiring that the type system can express them directly. In a sense the whole language can be used to define types. That’s a cool thing to be able to do, even if it means having to inspect documentation and method bodies to work out what they do.
They want to have a generic function that returns opaque types implementing different interfaces depending on the inputs. I've replied to that above.
You can provide more interfaces in Rust:
fn map(...) -> impl Iterator<Item=U> + Index<Target=U>
fn map(...) -> impl Iterator<Item=U> + ?Index<Target=U>
To allow that you would essentially need to say that "if the input implements `Index`, the output implements `Index`":
fn map<U, T, F, I, O>(it: I) -> O
where I: Iterator<Item=T>, U: From<T>,
O: impl Iterator<Item=U>,
I:?Index<Target=T> -> O:?Index<Target=U>
{
it.map(|t| From::from(t))
}
Notice that, for example, the output Range does not implement the same interfaces as the input range, e.g., the input Range implements an `Index` interface over a range of `T`s, but the output Range implements an `Index` interface over a range of `U`s. In D this is super implicit in the implementation details (body) of an equivalent `map` function, but in Rust it needs to be part of the type signature to avoid changes to a function body to silently cause API breaking changes. In D, you could change the body of map to map only from Range(T) -> Range(T), without changing its interface, and that would break all code using it to map a Range(T)->Range(U).
If I'm working in a typed language, and are dealing with functions max(a, b, c) and list(a, b, c), I would expect the documentation to say that one returns T, whereas the other a list(T). If it says auto, then I'm guessing from the names.
Maybe the target audience is programmers familiar with dynamic languages, who don't care so much and are used to reading the descriptions of functions about what is returned.
Having auto is a boon for certain design aspects. As system level programming language D offers everything in betterC mode. Of course it can offer more. But a small community can do only so much.
With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts like C++20, you could probably describe them with something looking like:
template<class R>
concept __SimpleView = // exposition only
ranges::view<R> && ranges::range<const R> &&
std::same_as<std::ranges::iterator_t<R>, std::ranges::iterator_t<const R>> &&
std::same_as<std::ranges::sentinel_t<R>, std::ranges::sentinel_t<const R>>;
Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.
Functor f => (a -> b) -> f a -> f b
Functor f => (a -> b) -> f a -> f b
Seems like you had some deep exposure to Haskell, ML or Hindley-Milner in general which, when excessively consumed, detaches from reality.
For one reason or the other you take this discussion serious and personal.
auto map(auto x) {
if constexpr(is_same<decltype(x), int>) {
struct T1 { int getStuff() { return 0; } };
return T1 {};
} else {
struct T2 { void doStuff() { } };
return T2 {};
}
}Ahh.. welcome to computer "science", the ever repeating cycle of 'inventions'
Which should have a type.
>and returns a type that iterates through that range
Which should have a type. The entire point is that this is a solved problem, there is no excuse to simply throw up our hands and say "screw documentation we'll just say this function is a mystery".
Functor f => (a -> b) -> f a -> f b
And please don't miss the point and tell me D doesn't have Functor. The entire point is that D has something, and it doesn't tell us what that something is. It should. Documentation is good.
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 something you can specify as a function attribute in D. Instead, ranges use a form of duck typing. The next step in the call chain can tell whether the previous step gave it something it can use using template inconditions, ie. `isInputRange!T`. But the previous step can't assert that it is returning a type that fulfills a constraint. In other words, there's type inconditions but not type outconditions.
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.
ceylon could, but they are barely readable anyway.
It does. That'd the `Range` here: https://dlang.org/phobos/std_algorithm_iteration.html#.map.m...
> > and returns a type that iterates through that range > Which should have a type.
It does. But the name of that type depends on the type of the range and on the callable.
> Functor f => (a -> b) -> f a -> f b
This doesn't work because the return type isn't `f b`, it's `g b` where g depends on what f is. It also depends on the callable, because the first parameter isn't necessary a function. The closest is
Callable c, Range r0 => c a b -> r0 a -> r1 b
Where `r1` isn't even a concrete type but a type that depends on both `c` and `r0` and is made up on-the-fly (per instantiation).
> Documentation is good.
I agree. How would you suggest improving the signature of map given that D doesn't have typeclasses? Or with types that depend on other types in the template?
is how you would define that class of types in Haskell. It says "If g is a range, then a pair of types f and g satisfy the FunctorTo interface[1] when knowing f determines g, and there's an implementation of fmapto with this type".
Maybe D needs typeclasses. This thread has certainly put me off of D, because being able to write down types is really quite important to me.
[1] The Haskell class keyword is defines something closer to an interface than an OO class.
The issue arises only with generic heavily templated functions. Nothing in D forbids you to write your programs with all types explicitly written down. That's btw how I mostly write my code.
That should not be a problem. It is a problem in D because of a lacking in D.
>How would you suggest improving the signature of map given that D doesn't have typeclasses?
The language needs fixed so it can express its own types.
It is not a problem, the compiler copes with it. The problem comes from the fact that such a type is absolutely not interesting to know how it is written. The unmangled type is unreadable.
When the return type actually matters, auto should be avoided unless there's no way around it. But that's why we have "Returns:" in Ddoc. The function signature itself is not the complete documentation. I mean, you're acting like all D functions are documented to return auto. They aren't. It's used where it needs to be.
The language expresses its types just fine (it's in the mangled name in the object file). The issue is that there is no point in the human readable form of these types.
Most people will tell you, "oh just use auto, it makes the code more generic". That's sweet, except as soon as I want to pass it to another function, I need to have the concrete type. Like you, I usually just copy-paste the full type from the error message and move on.
Of course good tooling is still a big requirement, but I still think it's the best decision in the long-term: it's way easier to improve and change tools like IDEs (especially with LSP?), rather than the language itself.
Regarding explicit types in functions, you also don't always need them in languages such as OCaml. I feel that the answer to your criticism could be to just have "auto" also for function arguments, especially when you're just prototyping.
There are many cases where the type is clear however or irrelevant or in generic code is hard to express (thus depending on documentation/comments unless obvious) which would also be hard to read.
for (Map.Entry<SomeLongType, AnotherLongType> x : someMap) {
final SomeLongType key = x.getKey();
final AnotherLongType value = x.getValue();
...
}
But if the body of the loop just refers to `x.getKey()` and `x.getValue()`, without extracting them into local variables, then it makes sense to put the exact `Map.Entry` type into the loop header.
for (Map.Entry<SomeLongType, AnotherLongType> x : someMap) {
final var key = x.getKey();
final var value = x.getValue();
...
}
for (var x : someMap) {
final SomeLongType key = x.getKey();
final AnotherLongType value = x.getValue();
...
}It's 2020. Why couldn't things work like this, where one can open a window for a concrete type using templates, and it shows the code?
If I say "A good CPU has more than two cores in 2020." then I'm just saying it's a requirement, not sufficient all by itself. I'm not calling a twelve-year-old phenom X3 a good CPU. The "in 2020" is just to emphasize that anyone failing this standard is falling behind the times.
https://devblogs.microsoft.com/cppblog/template-intellisense...
Now try that on vim.
MyClass myVar = new MyClass()
MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass var myClass = ...
Like, in C#
List<Account> accountsToDelete = accountService.GetAccountsToDelete();
repository.Delete(accountsToDelete);
var accountsToDelete = accountService.GetAccountsToDelete();
deleterService.Delete(accountsToDelete);
If your variables aren't informative when I'm reading the code, I'll be confused 5 lines later anyways. So make them informative at the start. And given that, doesn't that mean the List<Account> is a bit redundant?
At least that's what I understood.
In practice though, D codes fast and runs fast, as promised on the official site.
I wonder if the document could describe (in some regular way) how those auto types are constructed...from what input, with what operations?
Whether that's really what you want and whether that is the best approach to solve the problem at hand is a matter of preference and the problem space.
It is also allows for a "gradual typing" approach that Dart 1 had.
Could you please paste some example of a function that has a return value which is declared as auto?
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
It wasn't. They probably didn't look into the more "generic" functions e.g. hofs and algorithms.
The vast majority of functions in https://dlang.org/phobos/std_algorithm_iteration.html returns "auto"
A more explicit "impl(InputRange) map()" may be better until you consider that map is generic on the kind of range you give it, so that just turns into "impl(MapResult!R) map(R)()". A more roundabout, pointless way of saying "auto".
In feeble languages with simpleton typesystem may be, but in highly generic templated language like D it is not the case. The type is not dense at all.
What's funny is that in general people complain that compiler errors in D are unreadable. You know why they are unreadable?
Because they print out the types of the functions in which the error occurs and that is nothing more than word salad for generic functions.
Types with hundreds of characters are very common.
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.)
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?
auto auto map(Range) (
Range r
)A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun.
Maybe read and try to understand the complaint instead of pointing out something unrelated?
In general, this reduces to the principle that concrete is easier to reason about than abstract. The type signature of an unannotated function in a type inference system is maximally abstract, while (especially in practice) the signatures for functions that are manually annotated are more concrete if not fully concrete. There are still problems in non-type-inferred systems with programmers who try to be egregiously abstract, but these are fewer and farther between.
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.
Another reason is the (ironically) dynamic nature of a return type. E.g.
auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }
Template code can do that quite easily and then you don't have a choice but to write auto as the return value.
What would be fantastic if the documentation could be given access to the the compiler's return type inference, so that it could document the auto returns with a little more info.
Another way useful approach would be to implement protocols like in swift, or traits like in scala/rust/others, signatures in ml, etc. Then you would be able to define the interface of what a function returns.
There's a wanting implementation of a sumtype in the standard library (https://dlang.org/phobos/std_variant.html#.Algebraic), and a much better one as a package: https://code.dlang.org/packages/sumtype
The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif
Template arguments need to be known at compile time, and the extra set of parens is how templates parameters are declared in D.
Template declarations in D take 2 parameter lists. The first is the template parameters the second the runtime parameter: in auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }
we have (int i) as template parameter and () as an empty runtime parameter. In C++ syntax whatDoesItReturn<int i>()
at instanciation the syntax is different:
whatDoesItReturn!0() will instantiate a function returning an int
whatDoesItReturn!42() will instantiate a function returning a string.
I still think the best option is let the author describe it in ddoc, as the semantic meaning can be much easier to convey that way.
If the docs are filled with this, then D is certainly coming off my list of langs to look at.
For functions that can return different types, I think interfaces or union types would be more helpful (not sure if D supports either though).
I agree with your point, but for the sake of the audience who doesn't know D I think this example is misleading, as one could take the "int i" parameter as a runtime one, while it's actually a compile time one (the equivalent of C++ non-type template parameter). If you instantiate the function with 0 as a compile-time parameter, it is a function that returns int; otherwise it's a function that returns string. It is never a function that can return int or string.
Anyways, var/auto is critical in some cases. C#'s LINQ, for example, would be very difficult to develop with if you had to manually figure out the type you were returning with long queries every time you wanted to restructure your query.
- "D as a Better C" (2017): https://dlang.org/blog/2017/08/23/d-as-a-better-c/
- "Vanquish Forever These Bugs That Blasted Your Kingdom" (2018): https://dlang.org/blog/2018/02/07/vanquish-forever-these-bug...
- "DasBetterC: Converting make.c to D" (2018): https://dlang.org/blog/2018/06/11/dasbetterc-converting-make...
Only Active Oberon exposes non traced references, RAAI and a couple of other low level features that made it more complex to do systems programming in Oberon and Oberon-2, let alone Oberon-07.
Personally while D seems a great tool, I really keep running into situations where a language that lives on top of C/C++ is useful. So I’ve been trying out Nim for those use case, using the ARC GC which appears to work well for embedded. It’s deterministic but with move semantics for performance optimization. Interesting approach IMHO. But the biggest advantage is being able to directly interface with any C or C++ natively. D/Rust both seem to have difficulty being 100% onboard with C++ (for good reasons).
In any case here are the latest news on the subject,
"GTC 2020: Exterminating Buffer Overflows and Other Embarrassing Vulnerabilities with SPARK Ada on Tegra"
https://developer.nvidia.com/gtc/2020/video/s21122-vid
Another well know project that is now adopting Ada/SPARK is GenodeOS, https://genode.org/about/road-map
I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?
For libraries with a large API that can be an annoyance.
Note that all instantiations used in D code must be provided by linking to C++ object code or shared libraries containing the instantiations.
type StdMap {.importcpp: "std::map", header: "<map>".}[K, V] = object proc
...
var x: StdMap[cint, cdouble]
x[6] = 91.4
...
std::map<int, double> x;
x[6] = 91.4;
1: https://dlang.org/spec/cpp_interface.html#cpp-templates 2: https://nim-lang.org/docs/manual.html#importcpp-pragma-impor...
- Units (modules) for separate compilation with strong type checking and not needing useless prefixes
- A proper string type
- Proper arrays with bounds checking, it has functions to retrieve upper and lower bounds
- Allows the definition of numeric ranges
- Enumerations are their own type, can be used as array indexes or data sets
- Support for sets
- Thanks to reference parameters there is less need to deal with pointers that might be invalid
- Already allows for a simplified way of doing Type Driven Development
- Supports type safe function pointers
- Supports single inheritance OOP with minimal RAII support for heap allocated objects
- Comes with a quite powerful OOP framework for TUI applications, Turbo Vision
- While it doesn't prevent use-after-free, it allows for memory regions that can be deallocated on one go
- Can map arrays to memory regions with bounds checking
- Besides inline assembly without UNIX's clusmy syntax, allows to use registers as variables
- If one really wants do do unsafe C style coding there are compiler pragmas to allow it and yes even pointer arithmetic and unsafe casts.
This in 1992, if I take a recent version of Delphi, FreePascal or Oxygene, there are even more bullet points.
And it is not like many aren't actually coding in GCC C, Clang C, TI C, xlc C, aC C and so on.
Which even with those C extensions fail on the security story.
I think this kind of thinking is very common across the C community.
The ironic thing, is when someone makes that argument, they are admitting that the education they are giving creates students around the mean. When I teach someone, I try to give them a mental framework that others don't have and some unique skills that will differentiate them.
Learning C89 gives someone the "most chances" of getting a random job who hasn't upgraded to better technology (◔_◔). Where if I show someone how to use a constraint solver to optimize something, or how to run a quick Monte Carlo simulation to test a hypothesis, those folks will have a huge advantage over the C89 slinging autobot. The only reason to learn "popular tech" is to hide within a flock of nameless cogs.
> C99 block scoped variables free up stack space
I'm not sure that's actually true. Or at least if it is, I think it's the choice of a particular implementation. The compiler doesn't actually need to allocate anything until first use, and nothing prevents it from hoisting allocations earlier.
for (int i = 0; // ...
int i;
for (i = 0; // ...
(Declaring variables willy nilly anywhere in a block is nice too)
You can wrap the whole thing in an extra block, so at least you don't have to hoist `i` to the top of the function.
> (Declaring variables willy nilly anywhere in a block is nice too)
You can always introduce another block, although it's not uncommon that that's harder on legibility than just hoisting.
I have a lot of respect for you and Andrei, and I think D deserves much more love than it gets.
I personally feel like there are too many options when it comes to D. Perhaps it would be good to double down on some combination of those options and make that widely known?
As a newcomer to D, I am exposed to GC/non-GC code, dmd/llvm compiler/gcc compiler, several debuggers, some BetterC option, etc. I don't know which toolchain is best, and I don't want to deal with the integration issues between them.
All of these options that exist are great, but the brand gets diluted. D seems to be the ideal thing: it's seemingly a better C++, and a better C, with a clean syntax like Java.
I trust it's a better C, but how do I know the combination of the D toolchain that I'm choosing is better than sticking with the devil I know already?
What I would love to see is an opinionated package spun off from D. One compiler, one debugger, one IDE, one standard library. Make my onboarding experience better and take the thinking out of assembling a D toolchain.
Every time I find myself thinking "maybe I should look into using D instead of C for this project", I spend a few hours with D, and then I get frustrated at all the options and I go back to the devil I know.
I truly wish I could be one day convinced that I can install D and I get a solid platform without weird moving parts.
https://www.twitch.tv/videos/602715503 [edit: at 10:20]
From the reference I found[1], Andrew's stance is: The current zig tooling forces spaces instead of tabs because the tooling for the language is not yet complete. The self hosted compiler (which the community will start using just as soon as it's ready) already does accept both tabs and spaces.
So, I'm not able to understand your complaint at all. Perhaps you could you elaborate, provide a reference, or soften your stance?
[1]: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m...
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 abstraction over the hardware.
C has traditionally been used in a lot of places where Rust's USPs add a lot of value -- for instance in kernel development -- simply because there wasn't a safe alternative. 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, and Rust concepts which help safety like RAII just get in your way. Yes there are ways to get around this in Rust, but Rust is not really optimized for structured, manual memory management.
As a result I think there is plenty of room for something like C which just has better ergonomics and some more modern features.
In D, the ""borrow checker"" is being tacked on as an after thought, in an attempt to copy Rust. This means that it doesn't play nice with existing features and makes it difficult if not impossible to guarantee that memory isn't leaked or used after it was free'd. For example with exceptions. The checker doesn't check for exceptions and if memory is free'd correctly if an exception is thrown. This isn't a problem in Rust because it doesn't have exceptions so it doesn't have to worry about checking them so it can maintain its strong guarantee.
Rust does have something similar to exceptions when compiled with "panic=unwind" (the default). It uses the same mechanism as C++ exceptions to unwind the stack (while calling all the necessary destructors), can be caught (std::panic::catch_unwind) and rethrown (std::panic::resume_unwind), and has some of the same concerns as C++ about "exception safety" (mostly within unsafe code - the programmer has to take care to leave the objects in a safe state when it can unwind).
"only one mutable reference to a mutable object OR many const references to an object"
and that's where the similarity to Rust begins and ends. The realization of that principle is quite different.
There's really no point discussing this with you any further. You don't contribute anything to the discussion. That's just PR babble, and provides zero information and doesn't even deny the fact that exceptions break memory safety with D's borrow checker (you know it that's why you don't deny it like a "good" PR person).
So as long as UNIX clones exist C will be around. OSes with POSIX APIs is a different matter, because there the kernel can be something totally different, e.g. mainframes.
So for that, we still need something like Checked C.
Or as Oracle, ARM, Google are doing, hardware memory tagging.
So, yeah, really not a C replacement at all imo
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
fn eats_a_string(s: impl Into<String>) {
dbg!(s.into());
}
fn main() {
eats_a_string("foo");
eats_a_string("foo".to_string());
eats_a_string(&"foo".to_string());
}
I would enjoy reading a couple paragraphs, or a blog entry about this.
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 < C" anymore, since in some aspects newer languages do offer more low level control about certain things than C.
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".
So only the old generation remembers how things used to be, and those that are curious about the computing history and evolution of programming languages.
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? Skimming through it, it doesn't look like there's any compelling reason to switch to -betterC from an existing C++ code & knowledge base.
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 variables.
Sure, but D has those OO features, too, so that's an argument against both, not one.
> like that it's nice not to have to pass around array lengths as separate variables.
-betterC doesn't have dynamic arrays, though. That's one of the "unavailable features" currently.
But that's also sommething C++ solved as well - std::vector does exist, after all, as does move semantics to avoid copying it unnecessarily.
C++ is far from perfect, of course, but D's -betterC doesn't really fix any of C++'s issues and it doesn't retain C's simplicity. It's in an awkward middle ground between the two - is that really a viable place to be? For users that already know & have C++ codebases, what's the sales pitch here? For existing C users, what does -betterC do that hasn't already been done and already failed to attract the C holdouts?
You can get them in C++, and VC++ does it by default on debug code, but not all compilers do by default and it isn't required by the standard unless you explicitly make use of the at() variants.
On the other hand, every attempt to bring bounds checking to C has failed, lets see how far Microsoft goes with Checked C.
In particular, I really love that I seldom use operator new. Objects are instantiated in the stack and object creation is ridiculously fast.
True, but the trouble with simplicity is a number of things become excessively tedious and error-prone to code - such as ensuring no buffer overflows.
C makes up for its lack of expressivity by adding a text preprocessor. The preprocessor is a tacit admission that the core language simply isn't powerful enough. When people find themselves doing metaprogramming with the C preprocessor, it's really time to graduate to a more powerful language. DasBetterC doesn't need a preprocessor, and its metaprogramming facilities far outstrip the C preprocessor.
...and are severely crippled by applying betterC constraints to CTFE:
// CTFE-only
string genint(string name) {
return "int " ~ name ~ ";";
}
void main() {
mixin(genint("x"));
}
Which suggests an avenue I haven't seen anyone take yet: Pick a subset of features common to sane hardware and write a language which gives access to those features in a way which is reasonably portable and as explicit as C.
Pick a spot midway between a macro assembler and a language with a complicated optimizer and give as much access to the hardware as possible while not wedding yourself to a single ISA. Make cross-compilation a first-class feature using a module system, and error out if the programmer tries to use SIMD intrinsics when compiling for an MSP430 or something.
It basically follows on the school of thought at Xerox PARC, ETHZ, and Microsoft Research.
Now what it lacks is more more manpower to improve its runtime capabilities and having a big name actually pushing it forward.
However this doesn't need to be a zero sum game, any language that helps to fix C is welcomed to the party, including attempts like Checked C and Frama-C.
Yes, betterC does not use the GC, but I was speaking about the whole language, and many anti-GC folks eventually discover that they can stick to regular D and still deliver what they were trying to do.
You can imagine an OS written in D, where BetterC mode gets used in the layers that for whatever reason cannot afford a GC, while all the remaning layers can happily take advantage of it.
- Want to access member in a aggregate (class/struct)? Use .
- Want to access member in pointer to an aggregate? Use .
- Want to access member in a module? Use .
- Want to access reference (not free standing)? Use .
This makes switching between different implementations pretty easy. Coupled with UFCS, this is pretty fantastic!
Just do a template
void zeros(T)(ref T arr) { arr.each!"a = 0"; }
someArr.zeros;
It's a big boon that existing C projects can migrate one object file at a time to betterC, without needing to pull in extra dependencies. Moreover, embedded dev is where C is still the most entrenched due to its runtime simplicity (simple ctr0, linker script, and you're off).
I've used it myself to easily convert some of my older C programs to D and make them easier to maintain.
What's the story in terms of using existing C (or C++) code with BetterC or D in general?
I'd pick up a comprehensive book like Ali Cehreli's "Programming in D",
https://www.amazon.com/Programming-Tutorial-Reference-Ali-Ce...
and come hang out in the D forums:
You can mix and match C and D code easily in the same program, and to a lesser extent C++ code. This means a larger project can be incrementally converted to D while keeping it running and shipping.
* Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref. What's the thinking behind D's syntax?
* What's the state, and future, of precise garbage collection in D?
Mainly that it be easy and quick for those familiar with C and C++ to get up to speed. With C, C++, and D, you cannot really know what will happen with the argument without looking at the corresponding parameter declaration.
And are there any languages where lazy is not a failure in your opinion?
Edit: removed link to wrong swift feature proposal.
Is "Better C" Done? Or are there any features/changes being planned? Will it always stay backward compatible?
A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensitive parts of my (non-x86) code that were dominated by the compiler's builtin memcpy, due to my struct-happy coding style (e.g. rolling my own range struct and passing it by value everywhere).
I understand mostly why eliding argument copy is so much harder than eliding a return object copy, there are so many ways to observe its effect, and you have to obey the calling convention. Another aspect is the lack of programmer-communicated immutability in C, which you have addressed with D. Does the D compiler help in this situation? Can it guarantee that (immutable) argument copies will be elided in certain circumstances? (e.g. in file-scope static functions)
No, but it's an interesting idea I never thought of. By the way, passing by 'ref' works handily and avoids icky pointer passing, while being efficient. I recommend as a "best practices" coding style using 'ref' parameters instead of pointers where possible.
Not even with old compilers, necessarily, this is more about the CPU architecture. If you've got an architecture with no cache (eg 386 and below for Intel) you'll not care about cache miss vs cache hit, but once you have cache you'll often find that the pointer dereference will hit main memory, and thus be slower than just passing by value. Not always, of course, but sometimes, so since 1989 (for Intel) you've needed to profile that to be sure.
It was then up to the callee to make a copy if necessary, say if it modified the struct contents.
Hence it would have been possible to elide the copies, on a per function basis, depending upon how the function used the structure.
[1] ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.20.pdf
I was also thinking in the direction of the compiler transforming the call-by-value struct object argument into a call-by-ref one at specific call sites. e.g. when the object is clearly on the caller's stack, is not mutated by the function and the function is not taking its address.
As Walter pointed out, you can use refs in BetterC (and of course C++) directly, but I don't see why it cannot be automatically applied to C in general.
1. Why do functions need to be annotated with @safe and nothrow in betterC? Why not make them default? I understand making it default for non-betterC might break some code.
2. string type was uniform and awesome until it was treated as Unicode. Any plans to fix this and remove auto decoding? That would be awesome.
Edit: three questions to two. I had another question about using threads in betterC. But looks like we can't use D threads as they are runtime dependent.
2. I think you're referring to autodecode. There is an effort ongoing to extricate us from that, but it's difficult while maintaining backwards compatibility.
3. That's right. You'll have to use C threads.
- what is the status of the ecosystem now?
- what are the big issues that make d less appealing?
- ms alexandrescu is still involved in the project?
- where do you see the language in 2 years for now?
See their Oral Histories collection: https://www.computerhistory.org/collections/oralhistories/
We've got a paper on the history of D accepted into this year's History Of Programming Languages (HOPL), which makes us very proud. Andrei, Mike and myself spent a lot of time combing through old emails and n.g. postings to develop an accurate timeline of when and how things came about and from whom.
I was really looking forward to the HOPL conference in London in June to present the paper, but CV scuttled that.
What is your vision for D/betterC/SafeD?
Is the intention at the moment to stay as a systems programming language only, or is your vision that D or betterC or SafeD gain traction as an embedded target language?
I definitely think the focus on correctness and the ease of unit testing would be great in the embedded development space.
Contract-based programming is a very nice way to quickly find errors and specify how different parts of the program should interact.
There are some Java annotation processors that rewrite the bytecode for contracts.
As extra info.
It's another layer of complexity, but it extends the language to offer a bit more richness or layers of abstraction.
I would not be surprised if a future C++ standard adds contracts officially. Boost seems to already have contracts: https://www.boost.org/doc/libs/1_67_0/libs/contract/doc/html...
On the .NET side you have Roslyn, Attributes, expression trees and on F# quotations.
While they are all a bit cumbersome to use versus what Lisp macros allow for, they already allow for quite a lot.
Yes, there is some hope that C++23 will bring them.
The more languages support DbC the better, only so can we start seeing more widespread adoption across the industry.
Then again, I am biased.
printf("Hello %s", 123);
Compiling with GCC -Wall -Werror, the type error is easily caught by the compiler.
A subset of C++ is a better C, that can be written in such a way that C compilers translate it, so that is meaningful. Well, at least a slightly better C, anyway.
https://github.com/DigitalMars/Compiler/tree/master/dm/src/d...
It still looks a lot like C.
2. set up to compile with dmc prog.c -c -betterC
3. replace all the preprocessor stuff
4. compile it, and fix the errors diagnosed by the compiler
The hardest part will be how much metaprogramming was done using the C preprocessor. Once that's dealt with, the rest is fairly mechanical.
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.
Some excerpts "At one time, C was my go-to language for most programming. One day I realised that most of my C programs kept reimplementing things from C++: dynamic arrays, better strings, polymorphic classes, etc".
[1]https://theartofmachinery.com/2019/04/05/d_as_c_replacement....
Not that I'm suggesting this would be a better approach, but wouldn't it be possible to link both the C and D runtime libraries and wrap the main function to do the initialization?
All the features I like in D such as dynamic arrays and associate arrays are gone
- enumerate everything C is doing bad.
- presents fixes with a full bag of unnecessary features that no c programmer wants.
I wonder why there is no "Fixed C".
Fortunately, you can simply not use any feature you find unnecessary. We won't harangue you about it, I promise! (Well, maybe a little bit if it's so cool we just can't resist.)
So on Apple platforms they will eventually have to deal with C++ and Swift no matter what.
On Microsoft platforms, they complain about C support and get shown the door to C++.
And on Google platforms, given the years of ignoring security advices, starting with Android 11, hardware memory tagging is a required feature, with the kernel randomly attaching GWP-ASan to processes, while on ChromeOS Linux gets to run on a hypervisor sandbox.
That's the problem. This isn't a technology issue, it's a social one.
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 can sense that we only want a proper hygienic macro system.
And "array type", pointer with length, to deal with contiguous memory.
The rest is well described in the video, but those 3 points are my major issues.
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".
I can understand that "you don't have to use any features if you don't want to" is somewhat silly when talking about C++, since it has so many features that can bite you when you least expect it, especially when dealing with years of legacy code. D is far better designed than C++, however; it would not take you nearly as long to learn enough D to be comfortable reading others' code.
All I'm trying to say is that "C, but without the problems" might actually look more like BetterC than you think it does. True zero-cost abstractions are clearly still an unsolved problem, but abstractions are a necessity. C's niche is rapidly disappearing.
Also, out of curiosity, what don't you like about Zig? I saw this on your website, but I couldn't find any specific issues you'd had with it.
> Wow, Zig is competitive with assembly?
> Yeah, I totally had the same reaction. I’m interested to see how it measures up under more typical workloads. People keep asking me what I think about Zig in general, and I think it has potential, but I also have a lot of complaints. It’s not likely to replace C for me, but it might have a place somewhere in my stack.
It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages.
Even Zig fails to do better than C, I think it's syntactically a disaster.
Here is a few lines from the documentation:
const ptr = @intToPtr(?*i32, 0x0);
while (it.next()) |item| { /* ... */ }
pub fn main() anyerror!void { /* ... */ }
exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"});
const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }Here's what I see in your example:
- @ indicates built-in function, which avoids namespace collisions.
- Optional types via the ?, which solves the null pointer problem.
- Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications.
- The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator?
- anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here.
- It has interoperability with (multiple standards of) C.
- Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code.
So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.
I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax.
Since you took your time I will take mine to address what I don't like:
- There is no way to write "int" by default. I understand why. But I don't agree.
- struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c}
- You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not.
- You have to type const when importing module:
const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct.
var my_var: i32 = undefined;
- The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror
- About iterator I was doing well with:
while(get_next(context, &item)) { /* ... */ }
I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).
Don't get me wrong, I like to help people. But I learnt to not help people that do not seek help.
You get a plumber fixing your pipes because you need your pipes to be fixed, but if every single plumbers were offering there help it would be annoying.
There are already more that three hundreds proposals:
https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...
A lot of them are about the syntax. Maybe this won't be endless but I'm sure a lot of time are being wasted. The root of the issue I point seems to be bound to the way the devs are working. Not sure if it will be efficient to tell them to "think more carefully". I do believe my time can be more profitable elsewhere (like commenting here, ah ah).
D is designed to be very readable to the C programmer. Some changes, like replacing:
(int)(expression)
cast(int)(expression)
The D compiler actually recognizes the C form and suggests using the D form to fix it.
Converting C to DasBetterC is largely just a) eliminating use of the preprocessor and then b) making the syntax changes suggested by the compiler.
D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing.
Sorry for my selection of words (and for the unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same.
I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions.
I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.
Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc.
We encourage people to run their own benchmarks on their own code and let the results speak for themselves.
One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way).
It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked.
One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.
Oh, this is pretty sad...
Anyway thanks for your time. Was nice to interact with the author of D. I truly believe what you've done will inspire a lot of people.
I hope you didn't encounter too many people saying creating D was foolish.
I spent time checking about a lot of languages and only D (and Jai, but it's not released) would restore my joy of programming.
This is incorrect. There are other factual errors here as well.
The remaining C usage is a mix of existing domain expertise, existing large codebases impractical to migrate to anything else (eg, Linux), or a rejection of anything more than what C provides.
In all of those cases anything that's not exactly C is unlikely to motivate any changes. The users that could change to a "Fixed C" already did decades ago.
What I got: some 50,000 foot pure functional typeless language with loads of magic in the compiler that you'll never be able to reason about without having written one yourself.