Breaks C function call semantics

[chrants]

I’m gonna say it. The pipe operator obj |> func breaks the semantic style of javascript being a C-like language.

I’m not saying it’s bad, but it turns a C-like language semantically and syntactically into something pretty darn different. You call functions with (...args) You access object properties with obj.property. It’s shared amongst all C-like languages. This is familiar to developers coming from Java, C, C++, even Python, etc etc.

All of a sudden now you have a syntax that changes the semantic behavior of function calls into two distinct styles completely different -- the func(...args) way and the obj |> func way. It’s quite transparent for some, but quite obscure for others.

I don’t disagree with adding it into the language, but I don’t agree either. It seems to bring only a small short-hand syntax for something that can be implemented with a simple function definition or set of function definitions. ( #131 )

[chrants]

I think that concerns of whether this makes JavaScript harder to teach is also relevant (related: #82).

[ljharb]

You can also call functions by making them getters and avoiding the parens.

[chrants]

You're right that property access and assignment can implicitly call getter and setter functions on objects, but semantically the getters and setters themselves mean only property access and property assignment. Of course you can do wacky stuff with getters and setters, but the primary purposes for implicit getters and setters are to adhere to the property access and assignment rules in a more generic way. I'd hope this general semantics will be conserved with somebody writing getters and setters.

[ljharb]

To clarify: personally I think the semantics you're concerned about breaking here were already shredded in ES5 with getters/setters, and I see no value in attempting to preserve them further.

[chrants]

The value I suppose for preserving (what is left) of the C-style semantics is in the eye of the beholder. It is very relevant to it's teachability, I think. Having familiarity in semantics can ease people into the language. I think that the discussion in #82 or related discussions on teachability are very relevant for this issue.

[chrants]

That is, supposing that C-style semantics isn't mostly preserved with implicit getters / setters still. C# and probably others implement this implicit setters / getters as well. Are there any C-like languages that implement the pipeline operator in a similar manner?

[mAAdhaTTah]

Hack is C-like and implements a pipeline operator as well, although its version requires a placeholder.

[chrants]

It's great that there is a C-like language that has something similar for the familiarity factor. You don't want, after all, to introduce some syntax as opposed to something else, just because you can. That's good. Familiarity isn't everything, but it definitely eases barrier to adoption and hopefully the clarity of best-practices.

[chrants]

I'm thinking of other ways this breaking C-style function call semantics could break the semantic style of ES being a C-like language by looking at some real-world uses of the pipe operator. I will be back shortly about some actual code examples. Some postings that illustrate a function-definition vs a syntax defined pipe set of operations below would be.

Update: I'm brain-farting and failing to figure out a real-life circumstance where you would use it at the moment for comparison purposes. Help would be appreciated. The examples on this repo seem mostly contrived.

[TehShrike]

The "looking like C" ship sailed a long time ago. Most of modern JS's language features don't look like C at all.

And that's fine! Most developers learning to write code today are starting with a more modern language than C.

"Looking like other C-inspired languages" would make more sense as a priority to me than "looking like C" (though I wouldn't be a huge fan of that priority either).

[chrants]

The concern isn't that the syntax is not "like C", really. The concern is that it is not compatible with most C-family languages, or in fact most of the TIOBE index top-10 languages. I think that concern mixed with that it splinters function call syntax and that the syntax doesn't have much benefit over an alternative consistent with current syntax, though possibly some, such as a function definition included in the language instead ( #131 ). The concern isn't against a piping feature necessarily, just this particular approach that breaks C-style function call semantics.

[chrants]

To play devil's advocate on my own point, I think that this proposal for its implementation in PHP is relevant https://wiki.php.net/rfc/pipe-operator

[chrants]

In the end, I think that resolving this particular argument against the pipeline operator can be used in pushing forwards the pipeline operator even more, so I think that this discussion isn't bad for this project haha.

[StormBlade97]

I'd like to advocate for Chrant's idea. A function could simply do the job of this new operator.
I'd imagine it would be quite confusing if we have a separate operator for iterating / mapping / folding collection instead of the nowadays standard forEach map reduce.

This will be wayyy easier to adapt too. A change in operator (aka new syntactic rule) would mean lots of effort from transpilers (babel, ts, or even others that transpile kotlin, go, etc to JS). Plus all the cost in training etc.

[tabatkins]

Closing this issue, as the proposal has advanced to stage 2 with Hack-style syntax. (And afaict the Hack-style syntax addresses the OP's issue, as you still call functions with normal function-call syntax, etc.)