Hacker News Reader

Comment by ikurei | Hacker News Reader

I love named parameters. Whenever I use Python or Swift, I hate having to come back to languages like C or Javascript that don't have them.

It just seems like such a clear win to me, that and writing long numbers like 1_000_000. So much more readable.

Why aren't these features more common? I'm a bit surprised Typescript never added them. Are they too difficult to implement in compilers/interpreters? Do they cause too many issues for interop?

I'm honestly curious. Is it just that not that many people find these features appealing?

PD: I know you can emulate named parameters using objects in JS/TS. I don't love the performance consequences of this; it's good in some situations, but terrible in others.

View on HN

In C99 and later you can use a similar workaround as JS/TS with designated initialization for functions which take a struct by value or pointer.

E.g. for a function:

    void my_func(const bla_t* bla);

It would look like this:

    my_func(&(bla_t){ .x = 123, .y = 542 });

Designators can be in any order and can also be optional (missing items are zero-initialized, so the function should be aware of that and replace them with defaults.

C++20 has a much more restricted designated init feature (basically useless for complex structs), but one nice thing in C++ is that default values can be declared right in the struct declaration.

This is one thing I really appreciate about your API design in C/Zig -- the mindfulness of being idiomatic to use by passing (possibly nested) designated initializers.

I hope the C++ committee will fix their designated init feature implementation (atleast for POD structs) because this single feature makes the code 10x more readable.

> Are they too difficult to implement in compilers/interpreters?

No, not really. You just have to be aware of them, decide that you want to implement them, then sit down and implement them.

For numeric literals with underscores the implementation is rather trivial, you fiddle a bit with the lexer to make it skip the underscores during the text consumption and value conversion.

For named arguments the main problem is not in the implementation itself, it's deciding on what semantics you want when you mix named and positional parameters: e.g. if you have f(a,b,c) then what does f(1, 2, a=3) or f(c=1, 2, 3) or f(b=2, 3, a=1) mean?

C23 has C++14-compatible separators in numbers, as in 1'000'000. (Not sure why they didn’t use underscores.) Unfortunately, strtol and friends haven’t been extended accordingly.

The original C++ proposal [1] discusses some alternative syntaxes, including underscores. Underscores would conflict with C++ user defined literals, for example in 0xAA_BB it is unclear whether _BB is a literal suffix for 0xAA since it’s a valid identifier.

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n34...

In python the int parser was quietly changed to accept underscores as valid ints. This has bitten me very bad in production. Imo this was a very bad idea.

Yeah, literal int representation in source is one thing, changing int parsing string methods is something else and probably should require explicit inclusion.

How did this cause problems for you?

One system checked if it was a valid int by running `int(x)`, deciding that it was, and passing it to the other system. The second system ran a python version BEFORE this change, while the first system was a newer version. BOOM.

That was the first issue. But this made me extremely fearful in the general case, as parsing a number incorrectly can have quite dire consequences when dealing with money for example. So suddenly accept any random string of numbers interspersed at random places with underscores is a Bad Thing, and not a tiny little implementation detail to push through the most popular programming language in the world without any discussion.

it seems like, the way you designed your system, literally any backward-compatible change to integer syntax in python would cause the same parser-differential denial of service vulnerability?

C23 features won't help many C users because it's a community that takes an uncommonly long time to move to new versions. Linux only recently moved from C89 to C11.

TBF it makes little sense to change the language standard of an existing project because then you end up with large areas in the old standard and some areas in the new standard. And bringing the entire code base to the new standard is just pointless busywork and might actually introduce new bugs.

As long as Linux doesn't prevent user space code to be written in more recent C standards (which it obviously does) it's fine.

Apart from that, there's also the Visual Studio compiler team to blame because they didn't manage to catch up with C99 until around 2015 (and even then only an incomplete implementation), and only in 2019 decided to 'officially' support the latest C standards again.

In general it makes a lot more sense today to start new C projects in more recent standard versions then it was 5..10 years ago.

Strong agree on all points. The gains from bumping e.g. a C++ version are much higher.

The cost of pumping a C++ version is also much higher. For C, you lose support for older compilers and minor platforms that haven't catched up, but if this isn't a problem, then only very minor (or no) modifications to the source should be required. Newer features can then be used gradually where it makes sense.

> I'm a bit surprised Typescript never added them

TypeScript's pretty insistent on not adding features to the language that can't be "compiled" just by stripping types away. There was a little bit of slack around this early on (enums, most notably) but these days something like named parameters would probably be a non-starter until/unless JS implemented them first.

Also it’s easy enough to pass objects with named properties and destructure the object in the function parameters. So there’s no real need for named parameters anymore and it would just add another duplicative way of writing the same code.

JavaScript has named parameters, in sort of the same way that C has named parameters.

Get used to writing your functions using objects for the arguments:

  function myFunc({ foo, bar }) {}

Then you can call

  function myFunc({ foo: 1, bar: "x" })

Similarly in C/C++

    struct MyFuncArgs { int foo; char bar; };
    void myFunc(MyFuncArgs args) {}
    myFunc({ .foo = 1, .bar = 'x' });

You can use objects to imitate named parameters in JS/TS. I think that's widely used convention and most of my APIs use one object parameter instead of multiple separate parameters exactly because named parameters are awesome. With TS it looks clunky with all those type declarations, but I can live with that.

As to your question, I share this feeling. Naming parameters must be standard feature in every language. Absolute majority of functions would benefit from verbose calling syntax.

One issue with named parameters is that your public function argument names are always part of the public api, and thus any changes are a breaking change. It’s manageable obviously but pretty obnoxious because otherwise variable names are always part of the black box

Depending on your language design combinations of named and optional parameters can lead to some real problems, especially if you want to link to a different version of a library than the one you built with.

D has allowed underscores in numbers for as long as I can remember. They're implementing named parameters right now.

I’m glad named args aren’t in JS/TS.

Objects are good enough and it would add complexity for minimal reward.

Passing objects is less efficient than passing individual arguments in multiple ABIs though, even if the straight byte count would be the exact same

ABI is not a concern for JavaScript.

Even if JS does not have a "public" ABI, I'm pretty sure passing an integer will be faster than passing a new temporary object in at least multiple JS implementations.

All lisps, from Scheme to Clojure, have them under the name "keyword parameters"

Everyone knows lisps are superior, the trick is not to rub it in.

scheme (at least as of r5rs) doesn't have keyword parameters

Reply on news.ycombinator.com