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

311–320 of 360 posts

Re: Better C – A subset of D Programming Language

#311

Post by aldacron »

asdkjh345fd wrote: post #302
gallier2 wrote: post #255

Earlier quoted context omitted.

> 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.

Yes, the type is very interesting to know. That's why other languages make it known. Ignoring the entire discussion to reply twice with "nu uh!" is not very productive.

There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.

Re: Better C – A subset of D Programming Language

#312

Post by aldacron »

GordonS wrote: post #223
lumberjackstian wrote: post #182

Earlier quoted context omitted.

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…

I haven't looked at D yet, but... yuck ! `var` for return types in a method signature is seriously unhelpful! 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).

In the standard library, it's primarily in the range-based functions that you see this, where the type doesn't generally need to be known. And where you do see it, the documentation will describe what the function returns more accurately than any convoluted made-up type the function signature could show you.

Re: Better C – A subset of D Programming Language

#313

Post by aldacron »

F-0X wrote: post #152
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?

The major examples are parts of the stdlib which offer higher-level pipelines (some answers here indicate the need for such things to be very flexible in their return values to allow this, but this is not a priori obvious - Java manages similar functionality with just the Stream class after all). In this (and the sibling pages in algorithm) nearly every entry is listed as either "template" or "auto" rel https://dlang…

D's classes and interfaces are much like Java's, so it's possible and easy to write functions that express return types like that. It's also quite restrictive for generic programming. D's metaprogramming features are much more powerful. That means a template can return different types that do not conform to a single, easily-expressed interface. The std.algorithm package is built on that concept.

Re: Better C – A subset of D Programming Language

#314

Post by aldacron »

WalterBright wrote: post #265
bachmeier wrote: post #79

Earlier quoted context omitted.

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.

And the "Returns:" section!

Re: Better C – A subset of D Programming Language

#315

Post by petee »

Dylan16807 wrote: post #308
petee wrote: post #305

Earlier quoted context omitted.

Interactivity is a base attribute of an ide, and not the first reason people use it; the context here is that using an ide doesn't define a good programmer. So being able to clicky click is what makes good programmers to you?

They said that good devs use IDEs, not that IDE use makes you a good dev. Those are very different statements.

They said "A" good dev uses an ide, and a snappy 'in 2020' retort. It's plainly clear their intention is to imply only good devs use ide's in the modern era.

Re: Better C – A subset of D Programming Language

#316

Post by elcritch »

VHRanger wrote: post #297
e12e wrote: post #283

Earlier quoted context omitted.

> I really keep running into situations where a language that lives on top of C/C++ is useful. > 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++ I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?

You just need to do a bit of tiresome explicit declarations to statically link the code. For libraries with a large API that can be an annoyance.

AFAICT, D requires the C++ types be exported, included any predefined template objects or functions. E.g. you can’t dynamically wrap `std::map`, unless it’s already been instantiated in C++ library you’re linking. The same in Rust as well. See D Lang manual:

    Note that all instantiations used in D code must be provided by linking to C++ object code or shared libraries containing the instantiations.
Whereas Nim is one of the few languageS that can dynamically wrap C++ template types into its type system. Maybe Zig can do it too? See Nim manual [2].

    type StdMap {.importcpp: "std::map", header: "".}[K, V] = object proc
    ...
    var x: StdMap[cint, cdouble]
    x[6] = 91.4
    ...
    std::map x;
    x[6] = 91.4;
This makes it nice to wrap C++ libraries. :-)

1: https://dlang.org/spec/cpp_interface.html#cpp-templates 2: https://nim-lang.org/docs/manual.html#importcpp-pragma-impor...

Re: Better C – A subset of D Programming Language

#317

Post by dgellow »

kreco wrote: post #281
snazz wrote: post #260

Earlier quoted context omitted.

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

Thanks for spending your time explaining this. I think a lof people will understand those lines better. 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…

Did you reach Zig’s developer regarding the issues you mention? The language isn’t stable yet, good time to try to influence it if you think they are doing some mistake.

Re: Better C – A subset of D Programming Language

#318

Post by Dylan16807 »

petee wrote: post #315
Dylan16807 wrote: post #308

Earlier quoted context omitted.

They said that good devs use IDEs, not that IDE use makes you a good dev. Those are very different statements.

They said "A" good dev uses an ide, and a snappy 'in 2020' retort. It's plainly clear their intention is to imply only good devs use ide's in the modern era.

No, that's not how simple if statements work. I don't know what else I can say.

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.

Re: Better C – A subset of D Programming Language

#319

Post by WalterBright »

optymizer wrote: post #306

Mr. Walter Bright, I'm late to the party here, but I hope you will see my comment. 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 compi…

If you were to pick one option, stick with BetterC.

Re: Better C – A subset of D Programming Language

#320

Post by WalterBright »

exiled13 wrote: post #295
throwaway17_17 wrote: post #286

Earlier quoted context omitted.

What is the difference between the two?

Rust was designed from the ground up and every feature is implemented and designed to work with its borrow checker. So it is able to provide a definitive guarantee that memory isn't free'd or used after it is free'd. The only exception is in "unsafe" code, where you can break the borrow checker. But this limits where you have to worry about potential bugs. In D, the ""borrow checker"" is being tacked on as an after t…

D's version of Ownership/Borrowing adheres to the notion:

"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.

Post reply on HN