I think D is great for scripting.. and having no python experience but java/c/c++ it feels more familiar. The standard library is useful.
Better C – A subset of D Programming Language
261–270 of 360 posts
Re: Better C – A subset of D Programming Language
#262Re: Better C – A subset of D Programming Language
#263Earlier quoted context omitted.
I checked your link, each function has a “Returns:” section that describe what to expect. Isn’t that what you want from a documentation?
A type is much denser, than a textual description, and in most cases sufficient.
> A type is much denser, than a textual description, and in most >cases sufficient.
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.
Re: Better C – A subset of D Programming Language
#264Earlier quoted context omitted.
When it comes to templates it's not until instantiation time - when the compiler see the code being used. So this is just an issue during compilation. The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif
So the previous code wouldn't compile unless the compiler knew what values were going to be passed into whatDoesItReturn?
I missed this the first time, but there are two sets of parentheses in the example. Apparently the first set are like template parameters, and the second are the actual arguments to the function.
Re: Better C – A subset of D Programming Language
#265Earlier quoted context omitted.
It's helpful to bring up issues you are encountering in the D forums. This is the first I've heard of this particular one.
It's been raised many times before. By me and numerous others. The standard library is generic, which isn't the end of the world, but you can't tell from the documentation how you can work with the output. It's common for someone to ask a question and be told "add .array to the output". They'd never know that after reading the documentation.
Reading the example code in the documentation is very helpful with this.
Re: Better C – A subset of D Programming Language
#266One 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…
More a failure of documentation/tools? We've been content for a decade to just name the arguments and return without any context. Like the old joke "Where am I?" answered by "In a hot air balloon!". Correct but useless. I wonder if the document could describe (in some regular way) how those auto types are constructed...from what input, with what operations?
They already do.
Re: Better C – A subset of D Programming Language
#267The 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);
Compiling with GCC -Wall -Werror, the type error is easily caught by the compiler.
Re: Better C – A subset of D Programming Language
#268This 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
After I discovered C, I never wrote another line of Pascal :-)
Re: Better C – A subset of D Programming Language
#269Earlier quoted context omitted.
A compiler related question: 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 sensi…
The proposed NUBI ABI[1] for MIPS was interesting here in that for call by value if a struct was register sized, it would be passed in a register, but if larger it would be implicitly passed by reference. See section 3.4, Arguments. 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…
Thanks for the interesting pointer.
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.
Re: Better C – A subset of D Programming Language
#270Earlier quoted context omitted.
D also now supports Ownership/Borrowing (experimental) on a per-function basis, meaning it can be added incrementally to an existing program.
D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".
Yes, you do create accounts to follow D around and complain about it.