That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

`map` is an operation on a data structure that replaces one element with another, in this case `a` gets replaces with `idup(a)`. The `idup` makes a copy of its argument in memory, and marks the data is immutable.

So it's basically a pipe or like the pipe operator in some languages? Looks interesting.

It has a fairly direct analogy in some languages. A C♯ programmer reading the above will immediately recognize the analogy to .Select(), .ToArray(), and so forth from LiNQ.

* https://learn.microsoft.com/en-gb/dotnet/api/system.linq.enu...

* https://learn.microsoft.com/en-gb/dotnet/api/system.linq.enu...

Yup, it looks and behaves very much like Unix piping.

> That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

How would it look like with this particular code? Just for comparison.

> The `idup` makes a copy of its argument in memory, and marks the data is immutable.

How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

See https://en.m.wikipedia.org/wiki/Uniform_function_call_syntax - the examples section has two side by side. The Nim language version is also pretty readable even if you're not familiar with it.

As for idup... The first several search results for "dlang idup" are all useful.

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

I presume you really don't like perl, ML based (ocaml, f sharp, rust) Haskell or K.

I love Perl[1] and OCaml. I dislike the rest. It depends on the task.

[1] https://news.ycombinator.com/item?id=44359539

> As for idup... The first several search results for "dlang idup" are all useful.

Yes, I am sure it was, I am sure an LLM would have helped too, but I think that is besides the point here.

Is it beside the point? Looking at that perl example:

$string =~ s/\d+/NUM/g;

I don't have a clue what is going on. Sure, I see the regex, but what is =~ doing?

There's only so far you can stretch most languages before you need to actually put in effort to learn them.

"=~" is the operator testing a regular expression match. It should be obvious, because on the right side you see regex, and you ought to know what "=" or "==" does.

FWIW, I knew this as a kid, too, despite knowing absolutely nothing about the language at the time.

Anyways, you should read https://news.ycombinator.com/item?id=44463391 if you care about why I dislike the way D does it.

I don't think you're wrong, I have used D for 19 years and don't really use the UFCS dot style, it requires too much context. Just loops are more readable. In D you don't have much decisions forced on you tbh.

I just wrote a somewhat bigger program in D and I mostly used UFCS chains for the toString() overrides to have better debug outputs. There are also some idiomatic forms that are frequent like conversion bar = foo.to!int is much more readable than bar = to!int(foo)

I appreciate it.

> Reading the documentation?

Yes?

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

You said elsewhere that you love Perl. Would you say your sentence above applies to Perl?

I'm not a D user and I don't have a ball in this game. I just found your critique of D's syntax rather odd because it can be applied to basically any language one is not already familiar with. Maybe I'm wrong, but I don't think my response was particularly rude...

I mean, to me it just looks ugly. Perhaps written in a different way, it would have been better. I have seen Haskell and Elixir code, but they were much less ugly.

Then again, it is entirely subjective, and we should not argue about taste.

To each their own.

> > That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

> How would it look like with this particular code? Just for comparison.

I do not know how to write D, so the following might not compile, but it's not hard to give it a go:

    copy(sort(array(map!(uniq(byLine(stdin, KeepTerminator.yes)), a => idup(a)))), stdout.lockingTextWriter())

> > The `idup` makes a copy of its argument in memory, and marks the data is immutable.

> How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

Are you serious? You are offended by the idea of reading documentation?This is not helping the credibility of your argument. Again, I'm not a D user, but this is just silly.

> Why "a"

`a` is a parameter in the lambda function `a => a.idup`.

> Why "map!"

This is definitely something that can trip up new users or casual users. D does not use <> for template/generic instantiation, we use !. So `map!(a => a.idup)` means, instantiate the map template with this lambda.

What map is doing is transforming each element of a range into something else using a transformation function (this should be familiar I think?)

FWIW, I've been using D for nearly 20 years, and the template instantiation syntax is one of those things that is so much better, but you have to experience it to understand.

> "idup" seems arbitrary

Yes, but a lot of things are arbitrary in any language.

This name is a product of legacy. The original D incarnation (called D1) did not have immutable data as a language feature. To duplicate an array, you used the property `dup`, which I think is pretty well understood.

So when D2 came along, and you might want to duplicate an array into an immutable array, we got `idup`.

Yes, you have to read some documentation, not everything can be immediately obvious. There are a lot of obvious parts of D, and I think the learning curve is low.

Thanks for the reply.

> Yes, but a lot of things are arbitrary in any language.

I disagree, but to each their own.

> Yes, you have to read some documentation, not everything can be immediately obvious.

I do not disagree, but I wanted to know the rationale behind it ("map!(a => a.idup)")!

I think perhaps you are not realising the negative tone of your comments. There is no way to read "How is one supposed to know this? Reading the documentation?" except sarcasm. No amount of good faith in unrelated comment threads changes this. I believe that's why you're getting downvoted - not because people are easily offended about D, as you seem to believe.

Well, I did not intend my statement to be sarcastic. It was a genuine question. Blame my lack of social skills, or the fact that I am on the spectrum. I was curious about the implementation details, i.e. why "!" (in map), why "a", why "idup", etc. That is not to say I am reluctant to read the documentation, I am more than willing, but I wanted to know the story behind it. I have ideas, but they might be wrong. I do not want to guess when I can have a direct answer from Walter.

a!arg is used because I hated the look of a<arg> used in C++. (Using < > to bracket things when < means less than and > means greater than is always trying to short-circuit my brain.)

What makes the choice of < > for template parameter bad appears when someone tries to nest templates.

     a<b<arg>> 

and now a means greater becomes a shift right. That's one of the reason that it you had a genious ideo to find domething else in D

a(template params)(runtime params) at declaration a!(template params)(runtime params) at invocation with the type deduction and parenthesis omission making often even disappear completely the template syntax.

thank you

> I am an active speaker against people who hate reading the documentation.

How is one supposed to know this?

I dunno, check my comment history if you are so curious. Been down-voted for daring to say that people should be less reluctant to read documentation.

I refer you to the context of this discussion—how it is we got to be here:

> How is one supposed to know this? Reading[…]?

Are you asking me to find the comment where I stated that I "dislike" people who are reluctant to read documentation?

No.

Look, I will not comment on D any further because it seems like it gets down-voted for no reason. Take your positive comments if you so wish, no need to down-vote the ones that express different opinions. You won. I will not be commenting on it any further. I shall NEVER be expressing my opinions on this language, nor will I ever raise any questions regarding the motivation for its implementation details.

People are too quick to use the "down-vote" button, and are too quick to judge. I love documentation, I write them. I am an active speaker against people who hate reading the documentation. This was not a case against reading documentation, yet people - wrongfully - believed so. People always glance past things like: "not fond of", and "in my opinion". It is tiresome.

This thread could have been educational, but instead it was a thread meant to bash me. It is my fault.

You don’t like instance functions?

I do not like this in particular:

  stdin
        .byLine(KeepTerminator.yes)
        .uniq
        .map!(a => a.idup)
        .array
        .sort
        .copy(stdout.lockingTextWriter());

I would like to emphasize that this is a personal preference. No need to continue to bash me over it.

I prefer Elixir's |> operator, if you want an example of something I prefer.

What’s the difference?

    stdin
      |> byLine(yes)
      |> uniq
      |> map(a => aidup)
      |> array
      |> sort
      |> copy(stdout)

I’m sorry if you took it as bashing. It’s mere curiosity as I’ve never seen that preference before.

Is it a fair comparison? Would it work in Elixir? I have not seen it in Elixir projects as such.

Adjusting for the actual Elixir functions, yes that would work. That's how Elixir's |> works, it takes the value from the left and passes it as the first argument to function on the right. Which is what the chain of calls in D is doing.

I have not yet seen such long chains in Elixir. Could you show me a project where it is used?

"map(a => aidup)" caught me by surprise, too. Would Elixir do such a thing?

Thanks. I don’t know elixir.

For what it's worth, in Elixir you might write something along the lines of the following (this is a rough translation, I haven't tested it):

  IO.stream(:stdio, :line)
  |> Stream.map(&String.trim_trailing/1)
  |> Enum.uniq()
  |> Enum.map(&String.duplicate(&1, 1))
  |> Enum.sort()
  |> Enum.each(&IO.puts/1)

This is not equivalent in style or presentation to:

  stdin
      .byLine(KeepTerminator.yes)
      .uniq
      .map!(a => a.idup)
      .array
      .sort
      .copy(stdout.lockingTextWriter());

Personally, I find the D version visually unappealing (and confusing), especially the way "stdin" sits alone on its own line, followed by a sequence of indented method calls. The excessive use of dots combined with the indentation structure makes it look, to me, rather awkward.

That is just my own opinion.

You can format it whatever way you like. D does not use formatting to impose semantic meaning.

And yet... Perl is good with its chained operators acting on lists?

    print join '',
        sort { $a cmp $b }
        grep { !$seen{$_}++ } # = uniq
        <STDIN>;

I do not write such Perl code, but I have in the past.

Oh and by the way, it does not look that different from that of Rust. :) I have came across a lot of Rust projects.