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

161–170 of 360 posts

Re: Better C – A subset of D Programming Language

#161

Post by masklinn »

takeda wrote: post #154
self_awareness wrote: post #147

Earlier quoted context omitted.

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

Maybe it was fixed? I would imagine that saying in documentation that return type is auto is equivalent to not mentioning return type at all, so feels like something not intentional.

> Maybe it was fixed?

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"

Re: Better C – A subset of D Programming Language

#162

Post by thesuperbigfrog »

dmux wrote: post #117

Not included as part of the subset linked above, but D's Contract Programming piqued my interest: https://dlang.org/spec/contracts.html

Ada (https://learn.adacore.com/courses/intro-to-ada/chapters/cont...) and Eiffel (https://www.eiffel.com/values/design-by-contract/introductio...) also support contracts.

Contract-based programming is a very nice way to quickly find errors and specify how different parts of the program should interact.

Re: Better C – A subset of D Programming Language

#163

Post by EvenThisAcronym »

masklinn wrote: post #159
self_awareness wrote: post #147

Earlier quoted context omitted.

I've never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto. Could you please paste some example of a function that has a return value which is declared as auto?

https://dlang.org/library/std/algorithm/iteration/map.map.ht... 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.

Re: Better C – A subset of D Programming Language

#164

Post by EvenThisAcronym »

fluffything wrote: post #116
gmueckl wrote: 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…

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)) } infinitely more readable than fn map (it: I) -> auto where I: Iterator , U: From { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator `, even though the actual type cannot be named because of the anonymous closure. T…

Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.

Re: Better C – A subset of D Programming Language

#165

Post by SAI_Peregrinus »

yvdriess wrote: post #55
WalterBright wrote: post #4

Walter here - AMA!

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…

> A big reason is the good old 'passing by pointer is faster'

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.

Re: Better C – A subset of D Programming Language

#166

Post by Koshkin »

choward wrote: post #149
Pxtl wrote: post #134

Earlier quoted context omitted.

Hard disagree. MyClass myVar = new MyClass() is not DRY. It also makes it practical to use complicated structures out of generics/templates without killing the developer With , Declarations>.

Hard disagree. If you are assigning a value that's the result of an expression you might have somewhat complicated logic. Being able to say what you expect returned is very useful. MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass

Anything wrong with

   var myClass = ...
(or some other descriptive name of the variable)?

Re: Better C – A subset of D Programming Language

#167

Post by harikb »

kevin_thibedeau wrote: post #128
stcredzero wrote: post #103

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…

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

I agree. I will paraphrase this as - a well designed language should be usable, at minimum, from a pure text editor, and should not put unreasonable burden on an IDE.

Re: Better C – A subset of D Programming Language

#168

Post by lalaithion »

atilaneves wrote: post #139
asdkjh345fd wrote: post #75

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

> > 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 down types is really quite important to me.

[1] The Haskell class keyword is defines something closer to an interface than an OO class.

Re: Better C – A subset of D Programming Language

#169

Post by benibela »

kqr wrote: post #35

This 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

Re: Better C – A subset of D Programming Language

#170

Post by pjmlp »

entropicdrifter wrote: post #148
arunc wrote: post #72

Earlier quoted context omitted.

Why so?

You shouldn't need to reverse-engineer your own program just to understand the code you wrote yourself.

Apparently it is a common Go pattern to discover which interfaces a type implements.
Post reply on HN