From: "Gottlob Frege" <gottlobfrege@gmail.com> And in addition to the unexpected effects, it just doesn't read or look right.
from(str, 0)(more stuff);
really makes me think 'more stuff' happens AFTER the conversion.
Well, I am not sure I can agree that those mentioned "unexpected effects" is such a big deal. The "problem" with the deduced template parameters is the only "problem" I've come across so far. In fact, that issue is not unique to 'convert' and 'convert' addresses that is a fairly standard way. Granted, not having that 'hack' would be better.
This is one of the examples of why C programmers and many other language-ites just shake their heads at us. We can't seem to stick to writing code that even follows the rules of the language. (obviously the code, using a proxy, does follow the rules, but it doesn't look like it does).
I hear you. :-)
If you really want the multiple function call syntax, could we at least somehow put it first? ie (just one possible way), and note that 'convert' has become 'converter':
converter<int>(locale_ = loc)(throw_ = true).from(str, 0);
I am not sure why 'convert' had to become 'converter' so for the moment I'll stick with what exists already. That makes it int i = convert<int>(locale_=loc)(throw_=true).from(str,0); vs int i = convert<int>::from(str,0)(locale_=loc)(throw_=true); I am not sure. I'll have to sleep on it. Something is drawing me to the syntax you suggest but I am not sure what it is. What I like about the existing syntax though is its incremental flowing style: int i = convert<int>::from(str,0); // simple form int i = convert<int>::from(str,0)(locale_=loc); // with locale int i = convert<int>::from(str,0)(locale_=loc)(throw_=true); The above looks more predictable and flows better for me.
And as a bonus, I can reuse the 'converter' on the next line if I store it somewhere.
Yes, that functionality is already available (like one can use the same conversion with an algorithm) although maybe not in such an explicit form. That functionality was suggested, fairly straightforward to achieve within the existing framework, just did not get time to make it happen.
And you can still use the simple 'convert' (without the er) if no extra params are needed:
convert<int>::from(str, 0)
What I feel uncomfortable with is that "if this, use converter, if that, use convert, if this, use one syntax, if that some other syntax". To me that lacks predictability which is the first step towards familiarity that leads to confidence and acceptance (something any library writer wants).
And now it really does return an int.
After looking at the problem for a while I am not sure that 'convert' really returning a straight 'int' is achievable without denying many legitimate use-cases. Though I by no means can claim the last word in the domain. V.