How would you feel about adding the '/' binary operator and the '/=' assignment operator for strings, wstrings and dstrings? The operators would behave the same way as they do with boost::filesystem::path objects:

http://www.boost.org/doc/libs/1_54_0/libs/filesystem/doc/reference.html#path-appends

In short (and omitting some details) code such as:

string s = "C:\\Users" / "John";

...would be the same as:

string s = "C:\\Users" ~ std.path.dirSeparator ~ "John";

On 2013-07-02, 21:46, TommiT wrote:

> How would you feel about adding the '/' binary operator and the '/=' assignment operator for strings, wstrings and dstrings? The operators would behave the same way as they do with boost::filesystem::path objects:
>
> http://www.boost.org/doc/libs/1_54_0/libs/filesystem/doc/reference.html#path-appends
>
> In short (and omitting some details) code such as:
>
> string s = "C:\\Users" / "John";
>
> ...would be the same as:
>
> string s = "C:\\Users" ~ std.path.dirSeparator ~ "John";

This would be much better done with a library type:

auto s = Path("C:\\Users") / "John";

-- 
Simen

On Tuesday, July 02, 2013 21:46:26 TommiT wrote:
> How would you feel about adding the '/' binary operator and the '/=' assignment operator for strings, wstrings and dstrings? The operators would behave the same way as they do with boost::filesystem::path objects:
> 
> http://www.boost.org/doc/libs/1_54_0/libs/filesystem/doc/reference.html#path -appends
> 
> In short (and omitting some details) code such as:
> 
> string s = "C:\\Users" / "John";
> 
> ...would be the same as:
> 
> string s = "C:\\Users" ~ std.path.dirSeparator ~ "John";

That's what std.path.buildPath is for.

- Jonathan M Davis

On Tuesday, 2 July 2013 at 19:56:20 UTC, Jonathan M Davis wrote:
> On Tuesday, July 02, 2013 21:46:26 TommiT wrote:
>> How would you feel about adding the '/' binary operator and the
>> '/=' assignment operator for strings, wstrings and dstrings? The
>> operators would behave the same way as they do with
>> boost::filesystem::path objects:
>> 
>> http://www.boost.org/doc/libs/1_54_0/libs/filesystem/doc/reference.html#path
>> -appends
>> 
>> In short (and omitting some details) code such as:
>> 
>> string s = "C:\\Users" / "John";
>> 
>> ...would be the same as:
>> 
>> string s = "C:\\Users" ~ std.path.dirSeparator ~ "John";
>
> That's what std.path.buildPath is for.
>
> - Jonathan M Davis

Oh, I hadn't noticed that function. I don't know about its behaviour of dropping path components situated before a rooted path component. Throwing an Exception would seem like a better behaviour in that situation.

On Tuesday, 2 July 2013 at 19:46:34 UTC, TommiT wrote:
> How would you feel about adding the '/' binary operator and the '/=' assignment operator for strings, wstrings and dstrings? The operators would behave the same way as they do with boost::filesystem::path objects:

There is a *massive* difference here. boost::filesystem adds the
overload for *path* objects. It doesn't add a global operator for
any indiscriminate string.

On Tuesday, 2 July 2013 at 20:31:14 UTC, monarch_dodra wrote:
> On Tuesday, 2 July 2013 at 19:46:34 UTC, TommiT wrote:
>> How would you feel about adding the '/' binary operator and the '/=' assignment operator for strings, wstrings and dstrings? The operators would behave the same way as they do with boost::filesystem::path objects:
>
> There is a *massive* difference here. boost::filesystem adds the
> overload for *path* objects. It doesn't add a global operator for any indiscriminate string.

As far as I can tell, Phobos already uses strings or const(char)[] to represent paths all over the place. So, I figured, we can't add a separate Path type at this point because that train has passed. Although, I don't know if that design would have been a better anyway. Division operator for strings doesn't make any sense, and I doubt there will ever be some other meaning for '/' that would make more sense than "a directory separator" for strings in the context of programming.

On 7/2/2013 1:47 PM, TommiT wrote:
> Division operator for strings doesn't make any sense,

That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.

On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
> On 7/2/2013 1:47 PM, TommiT wrote:
>> Division operator for strings doesn't make any sense,
>
> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.

Before C came along, '<<' meant "much less" ...

On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
> On 7/2/2013 1:47 PM, TommiT wrote:
>> Division operator for strings doesn't make any sense,
>
> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.

I've never thought of it like that. At some point I remember writing a vector type which overloaded its binary * operator to mean dot product (or cross product, I can't remember). So, you can overload an operator, but you can't overload the meaning of an operator.

On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote:
>
> I've never thought of it like that. [..]

Boost Filesystem overloads the meaning of / to mean "append to path". Boost Exception overloads << to mean "add this info to this exception". Boost Serialization overloads << and >> to mean serialize and deserialize, and & to mean either one of those.

So no wonder I was under the impression that we're allowed to overload the meaning of operators.