/ as path concatenation

[arvabalazs]

C++ standard library provides a way to use / operator to concatenate paths:
https://en.cppreference.com/w/cpp/filesystem/path/operator_slash

I think for CUE this would be a nice readability improvement too:
p: "folder_name"/"subfolder" would be evaluated to "folder_name/subfolder".
Basically operator/ would do a concat like operator+ but also add a path separtor to it.

[myitcv]

The path package exists for path manipulations, including platform-aware filepath concatenations. Is there something you think is missing from that package?

[arvabalazs]

I do not know the operators are defined on package level or defined by the spec, but I talking about the behavior of / operator. It may be defined for string-string binary operation. Example:
a: "path"/"to"/"something" // a=="/path/to/something"

[slewiskelly]

But what compelling reason would there be to add this when there is a perfectly fine way of doing this via the mentioned path package?

import "path"

a: path.Join(["path", "to", "something"])

This approach is also likely to feel familliar to more people, as it is similar to how the same thing is done in many other popular languages.

[arvabalazs]

-- What is the compelling reason to support a+b+c instead of Math.add([a, b, c])?
The reason is the same: a DSL can "fine-tune" its notation to support the most frequent use-cases. In the configuration-business paths are pretty frequent objects. Of course in other hand, a DSL should no support every crazy DSLs from the world.

Anyway I understand your concerns about the familiarity, this is just an idea. I would use this operator/.

[slewiskelly]

What is the compelling reason to support a+b+c instead of Math.add([a, b, c])?

This is not a fair comparison, arithmetic operators are primarily used for creating mathematical expressions, and is natural to a great many of people. The same cannot always be said for other uses of them.

[arvabalazs]

It was just a corner example, but there are lot of others, which are interesting in terms how and why are they added to a language: binary float addition, logical &&/||/!, rem/div/quo, &. It can be said now they are well known, but when they actually was added to a (other) language years ago they were new. So the argument against logical! would have been "no compelling reason to add this because nobody know what is it, and the logical_not(p) function is perfectly fine".

I am not saying this argument is wrong, I am just saying it is not sufficient to decline the idea.

Of course as the designer it is your decision/responsibility what and how include into cue. I wanted to highlight that adding more convenient support for paths is not the devil :)