Add std.functional.bind

[pbackus]

Fixes Issue 22736 - Add destructuring bind for std.typecons.Tuple tuples

---

This version works for all struct types, not just std.typecons.Tuple. See #8372 for discussion.

[dlang-bot]

Thanks for your pull request and interest in making D better, @pbackus! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	22736	enhancement	Add destructuring bind for std.typecons.Tuple tuples

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#8376"

[CyberShadow]

Thanks!

See #8372 for discussion.

To summarize a lot of it, I'm hesitant about such an addition to Phobos because I can't see many use cases outside tuples, and it is so broad that it allows doing e.g.:

struct Coordinate { float longitude, latitude; }
Coordinate c;
...
c.bind!((latitude, longitude) => /* OOPS */);

Note that the JavaScript equivalent behaves correctly:

let c = {longitude: 12, latitude: 34};
(({latitude, longitude}) => /* OK */)(c);

I think we actually can make the D construct behave like the JavaScript one if we wanted to, which is why maybe that should be a separate discussion from #8372.

[pbackus]

Here's a non-std.typecons.tuple use-case that I almost included in the examples:

int[string] cityPopulations = [
    "New York" : 8_804_190,
    "Los Angeles" : 3_898_747,
    "Chicago" : 2_746_388,
    "Philadelphia" : 1_603_797,
    "Seattle" : 737_015,
    "Boston" : 675_647
];

// Print names of cities with populations > 1mil and < 5mil
cityPopulations.byKeyValue
    .filter!(bind!((name, pop) => pop > 1_000_000 && pop < 5_000_000))
    .map!(bind!((name, pop) => name))
    .each!writeln;

• byKeyValue uses a non-std.typecons.Tuple struct as its element type, so a Tuple-only version wouldn't work here.
• Using bind lets us have meaningful names (name, pop) instead of generic ones (key, value).

[CyberShadow]

byKeyValue uses a non-std.typecons.Tuple struct as its element type, so a Tuple-only version wouldn't work here.

There is std.array.byPair which does return a range of Tuple.

[pbackus]

I think we actually can make the D construct behave like the JavaScript one if we wanted to

Sadly I don't think this is possible in library code without resorting to string mixins, but I'd be delighted to be proven wrong about that.

[dukc]

Why not static asserts instead?

[pbackus]

This is copy+pasted from std.sumtype, and it uses runtime assert there too.

[ljmf00]

Can't this be in a shared module? I don't see the reason for a runtime assert.

[pbackus]

Once this is merged I plan to submit a separate refactoring PR addressing these issues. Since this PR introduces a new feature, I want to keep refactoring out of it.

[CyberShadow]

@atilaneves Thanks! Though, I'd love a rationale of your choice.

[atilaneves]

@atilaneves Thanks! Though, I'd love a rationale of your choice.

It's more general, and I didn't see why constrain it to tuples.

[RazvanN7]

This still needs a changelog entry.

[CyberShadow]

It's more general, and I didn't see why constrain it to tuples.

It's discussed in the other pull request and #8376 (comment). (Not sure if you didn't see the discussion or if you found it unconvincing.)

Edit: Well, I won't say no to a more generic version if the BDFL says the concerns are not worth worrying about 😄 Thanks @pbackus for the nice implementation!

[atilaneves]

It's more general, and I didn't see why constrain it to tuples.

It's discussed in the other pull request and #8376 (comment). (Not sure if you didn't see the discussion or if you found it inconclusive.)

I saw and read it, yes, I was more convinced by the other arguments. I hope that makes sense!

[RazvanN7]

I find it confusing that only struct fields are mentioned here. tuples should be mentioned too

[CyberShadow]

Do you mean language tuples (like in AliasSeq) or std.typecons tuples? The latter are just structs.

For language tuples you can just use the Identity template.

[RazvanN7]

I was referring to std.typecons.tuples.

[RazvanN7]

Maybe we can fix core.lifetime.forward.

[pbackus]

Not possible, unfortunately—forward takes its argument as an alias template parameter, and so does not have access to the this pointer at runtime.

[pbackus]

@RazvanN7 Added a changelog entry.