Unified Call Syntax

[Mr Flibble]

Herb Sutter's new "Unified Call Syntax"
(https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
initial idea gave me a mental rash though).

/Flibble

[Juha Nieminen]

I didn't understand how it's supposed to work with functions in
namespace.

He gives as example "file->fseek(9, SEEK_SET)", but fseek() is
in the std namespace. How exactly is it supposed to work? (What
if there are several functions named 'fseek' in several different
namespaces? Or are you supposed to do "file->std::fseek(...)"?
In the latter case, what's the advantage?)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[peter koch]

Also look at N4174. Have not had the time to study them yet.

/Peter

[Ben Bacarisse]

Juha Nieminen <nos...@thanks.invalid> writes:

> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> Herb Sutter's new "Unified Call Syntax"
>> (https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
>> initial idea gave me a mental rash though).
>
> I didn't understand how it's supposed to work with functions in
> namespace.
>
> He gives as example "file->fseek(9, SEEK_SET)", but fseek() is
> in the std namespace. How exactly is it supposed to work? (What
> if there are several functions named 'fseek' in several different
> namespaces? Or are you supposed to do "file->std::fseek(...)"?

Ruling out the case where file points to something with an fseek method
(which is tried first) I understood his suggestion to mean that the
compiler treats the call exactly as if it were written

fseek(file, 9, SEEK_SET);

and, if that fails and the extended version of the idea is being used,
the compiler tries

fseek(9, file, SEEK_SET);

and then

fseek(9, SEEK_SET, file);

I.e. the new syntax is just sugar for one or more function calls that
are tired in succession by applying the existing rules for name and
overloading resolution.

> In the latter case, what's the advantage?)

Pass.

--
Ben.

[Marcel Mueller]

Hmm, it looks like a reinvention of .NET extension methods.

What I dislike is the arbitrary preference of one parameter. On the
other hand it is a neat way to provide derived interface methods without
blowing up the interface.


Marcel

[Juha Nieminen]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> He gives as example "file->fseek(9, SEEK_SET)", but fseek() is
>> in the std namespace. How exactly is it supposed to work? (What
>> if there are several functions named 'fseek' in several different
>> namespaces? Or are you supposed to do "file->std::fseek(...)"?
>
> Ruling out the case where file points to something with an fseek method
> (which is tried first) I understood his suggestion to mean that the
> compiler treats the call exactly as if it were written
>
> fseek(file, 9, SEEK_SET);
>
> and, if that fails and the extended version of the idea is being used,
> the compiler tries
>
> fseek(9, file, SEEK_SET);
>
> and then
>
> fseek(9, SEEK_SET, file);
>
> I.e. the new syntax is just sugar for one or more function calls that
> are tired in succession by applying the existing rules for name and
> overloading resolution.

So are you saying it wouldn't work with functions inside namespaces
(such as fseek)?

[Jouko Koski]

"Juha Nieminen" wrote:
> So are you saying it wouldn't work with functions inside namespaces
> (such as fseek)?

Would something stop current argument-dependend lookup working?

--
Jouko

[Ben Bacarisse]

Well all names are in namespaces so yes, but on a technicality. fseek
might be in std:: or it might be in the global namespace, so the example
(not mine, BTW) could have been clearer. As I understand it, the -> (or
.) form is simply equivalent to the ones I listed, so if fseek is not
available in the current namespace file->fseek(...) will fail. If fseek
is only in std:: then you'd have to write file->std::fseek(...). In
other words, I don't think there is any intention to disrupt how
function names are currently resolved with regard to namespaces.

--
Ben.

[Juha Nieminen]

If (and given that) FILE is a type inside the std namespace, I see
how it could work without having to specify the std:: prefix.

However, I can easily imagine a situation where the type of the
parameter and the function are in different namespaces.

[Norbert_Paul]

Somehow makes me think of
http://clhs.lisp.se/Body/07_f.htm

[Jouko Koski]

"Juha Nieminen" wrote:
>
>Jouko Koski <joukokos...@netti.fi> wrote:
>> "Juha Nieminen" wrote:
>>> So are you saying it wouldn't work with functions inside namespaces
>>> (such as fseek)?
>>
>> Would something stop current argument-dependend lookup working?
>
>If (and given that) FILE is a type inside the std namespace, I see
>how it could work without having to specify the std:: prefix.
>
>However, I can easily imagine a situation where the type of the
>parameter and the function are in different namespaces.

Currently one would need a using declaration, a using directive, or an
explicit namespace qualifier in order to resolve the function in such
situation. Would this be actually much different?

--
Jouko

[j...@cppcon.org]

I like, but I'd very much advocate for including choice C in his answer to the question "Why not do the reverse, extend the nonmember call syntax to find members?" I see no reason not to do this and I think it very much adds to the proposal.

Jon

[Martin Ba]

What I don't buy is that we need a /language/ feature to enable IDEs to
offer sane auto completion.

Any "Intellisense" implementation today could offer to select and then
rewrite `x.f()` to `f(x)`. It would make sense with or with this being
in the language.

Aside, it seems though that
[D.2](http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394)
does also have this, so there's even prior art apart from .NET :-)

--
Like any language, C++ allows you to shoot yourself
in the foot -- but with C++, you sometimes don't
realize you shot yourself until it's too late. (Jeff Langr)

[Öö Tiib]

Herb Sutter has interesting idea, but he needs to think it through
bit more.

First he concentrates too much on that benefit of autocomplete
feature of IDE. However for me it is not such a problem to type but
more important is to read.

When reading syntax 'a.f1(b)' I know that 'a' is the 'this' parameter
(an IN-OUT parameter) of call. 'a' is passed by reference.
Even more when reading syntax 'a->f2(b)' I know that '*a' is the 'this'
parameter (an IN-OUT parameter) of call and it is caller who
dereferences 'a' here (and so must make sure that it is legal to).

The proposal removes that clarity since it does not talk about how
to match conceptual nature of parameters picked or responsibilities
of caller.

There was other benefit he mentioned that this will be somehow good in
generic context (template). However there he leaves too much open to
be convincing.

* He does not describe that array-to-pointer decay and how it interacts
with pointer parameters used with that extended syntax.
* He does not describe objects with unary * and -> operators overloaded
and how these interact with that extended syntax.
* He does not talk about other callables (lambdas, functors, function
pointers and function templates) and how these interact with that
extended syntax.

However we often alternate raw pointers (and above-mentioned decayed array)
with iterators or smart pointers (and whatever pointer-likes) in
generic context and we alternate functions with other callables.
So unless these are also addressed the "more generic" is rather
questionable point.

On the other hand if to make it very generic then it feels like another
tool of making code less readable in style of ...
'"otput.txt"->std::freopen("wb",stdout)' or something like that.

Also I imagine that lot of things in libraries (and in C standard library)
only have to look like functions but may be actually macros. That will
also fill StackOwerflow with novice questions about particular
library implementation with what the extended syntax does not compile.

So it does feel interesting idea indeed but it may lose lot of clarity
code and cause confusion and so it is strange that such a good author
like Herb Sutter did not write about those aspects at all.