Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

Post reply on HN
Print view View original

251–260 of 360 posts

Re: Better C – A subset of D Programming Language

#251

Post by FreeFull »

oconnor663 wrote: post #173
neutronicus wrote: post #121

Earlier quoted context omitted.

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 a…

There is a Rust idiom that works a little bit like that overloading case: fn eats_a_string(s: impl Into ) { dbg!(s.into()); } fn main() { eats_a_string("foo"); eats_a_string("foo".to_string()); eats_a_string(&"foo".to_string()); } In that case, eats_a_string() will allocate internally in the first and third cases, but it won't allocate in the second case, because the caller gives up ownership of its own allocated Str…

This sort of pattern tends to be more useful in case it's something like `CustomString` rather than just a regular `String`, and you still want your function/method to work with regular string literals. Also, other similar usecases, where there's a custom type that can be made from a standard type.

Re: Better C – A subset of D Programming Language

#252

Post by gallier2 »

RandallBrown wrote: post #221
lumberjackstian wrote: post #210

Earlier quoted context omitted.

Depends on the value of the template parameter. If it's 0 the return type is an int, if it's not 0 the return type is a string. 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

Interesting, so the return type isn't known until runtime.

No. It is known at compile time.

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()

at instanciation the syntax is different:

whatDoesItReturn!0() will instantiate a function returning an int

whatDoesItReturn!42() will instantiate a function returning a string.

Re: Better C – A subset of D Programming Language

#253

Post by lultimouomo »

lumberjackstian wrote: post #182
F-0X wrote: 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 felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…

> auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

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.

Re: Better C – A subset of D Programming Language

#254

Post by takeda »

arunc wrote: post #76
F-0X wrote: 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…

Vim vs emacs, auto inference vs explicit, I don't think it will ever end. :)

I don't know D, but after reading more comments looks like auto is also compensating for poor type system. For example functions that accept arguments of many types apparently need to be declared that are returning auto.

At least that's what I understood.

Re: Better C – A subset of D Programming Language

#255

Post by gallier2 »

asdkjh345fd wrote: post #197
atilaneves wrote: post #139

Earlier quoted context omitted.

> > It takes an input range > Which should have a type. 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`,…

>But the name of that type depends on the type of the range and on the callable. 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.

> That should not be a problem. It is a problem in D because of a lacking in D.

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.

Re: Better C – A subset of D Programming Language

#256

Post by gallier2 »

asdkjh345fd wrote: post #197
atilaneves wrote: post #139

Earlier quoted context omitted.

> > It takes an input range > Which should have a type. 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`,…

>But the name of that type depends on the type of the range and on the callable. 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.

> The language needs fixed so it can express its own types.

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.

Re: Better C – A subset of D Programming Language

#258

Post by gallier2 »

lalaithion wrote: post #168
atilaneves wrote: post #139

Earlier quoted context omitted.

> > It takes an input range > Which should have a type. 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`,…

class Range g => FunctorTo f g | f -> g where fmapto :: Callable c => c a b -> f a -> g b 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…

> because being able to write down types is really quite important to me.

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.

Re: Better C – A subset of D Programming Language

#260

Post by snazz »

kreco wrote: post #250
ddevault wrote: post #145

Earlier quoted context omitted.

Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't h…

Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. 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…

Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering?

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.

Post reply on HN