Earlier quoted context omitted.
I know nothing about Zig.
You should probably address that. It's a serious competitor to D (as better C). At the very least, you might see some ideas worth stealing!
[deleted]
Better C – A subset of D Programming Language
111–120 of 360 posts
Re: Better C – A subset of D Programming Language
#112Ohh! Ohh! C and C++ are used. How about ℂ (double-struck C) to mean "Like C but double the fun!"
Re: Better C – A subset of D Programming Language
#113Re: Better C – A subset of D Programming Language
#114> To link D functions and libraries into C programs, it's necessary to only require the C runtime library to be linked in.
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?
Re: Better C – A subset of D Programming Language
#115One 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?
Re: Better C – A subset of D Programming Language
#116One 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…
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…
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))
}
fn map(it: I) -> auto
where I: Iterator, U: From
{
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.
Re: Better C – A subset of D Programming Language
#117Not included as part of the subset linked above, but D's Contract Programming piqued my interest: https://dlang.org/spec/contracts.html
Re: Better C – A subset of D Programming Language
#118Regarding 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?
Re: Better C – A subset of D Programming Language
#119One 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 been using D since 2009 both personally and professionally. 'auto' return did bother me in a few places but it never came close to being a deal breaker.
Re: Better C – A subset of D Programming Language
#120Earlier quoted context omitted.
>It takes an input range 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 poi…
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.