Gottlob Frege <gottlobfrege <at> gmail.com> writes:
...
0. using named parameters - is this still debatable, or pretty much decided
I'd say anything is debatable and open for a discussion. Although some aspects have been discussed at length when the thread was somewhat more active. As for "decided" it feels too hard a word as people have varying opinions and preferences and I am inclined to try to accommodate those preferences (if possible) rather than "decide" on something. I am trying not to decide on anything but rather let pieces fall off based on the usage experience. I admit mainly using my own experience as a guide as I do not have much other input. As for named parameters, the interface is there and I was not rushing to take it out as I remember some people argued strongly in its favor. My only complain/observation was that my personal impression was that it was only of limited usage (for locale and throw). I was not alone advocating that stretching it further (radix, etc.) was counter-productive.
1. how to list params: (locale_ = locale)(throw_ = true) vs (locale_ = locale, throw_ = true) vs ((locale_ = locale, throw_ = true))
It's pretty much "decided"... for now. :-) Simply because ((...)) looks very odd and I personally do not want to give that syntax the user. Then, (,) (as I understand) has its limitations and requires deploying Boost.Parameter macros which I am not comfortable with. Then, the ()() chaining syntax is standard/familiar, scales well and does not impose any limitations or typing penalties. Sounds like a clear winner to me. The usual i-can-be-wrong disclaimer.
2. where to list params: from(str, 0)(more stuff) vs from(str, 0).with(more stuff) vs (more stuff).from(str, 0)
When this discussion started (or rather re-started) I revisited the 'convert' implementation and my design decisions. *I* am convinced that convert<TypeOut> and even convert<TypeIn, TypeOut> do not work in general terms and the delayed 2-step specialization (1-st on the TypeOut via convert<TypeOut>, 2-nd on the TypeIn via from()) is essential. Therefore, I *currently* feel that the suggested (more stuff).from(str, 0) interface won't work. As for Rob's from(str,0).with(more stuff) I do agree that it clears up whatever confusion there might be and I am prepared to incorporate that if there is enough support for it. I personally just can't help thinking that we are trying a bit too hard spelling everything out -- it's not the trickiest of all interfaces (many Boost components come to mind) and the seasoned users are unlikely to need 'with'. The beginners will need to read the documentation anyway.
3. returning an int (well, whatever the To type is)
I'd love 'convert' to return TypeOut directly. I feel that it cannot. Have you had a chance to read the documentation that is in the Vault with the 'convert' implementation? There I tried to cover various scenarios. That said, I feel that for simple cases 'convert' behaves *almost* like it returns TypeOut directly. The only wrinkle was using the result in template functions like template<class T> void foo(); foo(convert<int>::from(s)); For that there is foo(convert<int>::from(s).value()); or foo<int>(convert<int>::from(s));
4. use cases: function object, direct call, etc
I tried to cover the use-cases that I personally deploy and those that people mentioned and I could think of in the document that comes with the implementation (in the Vault). If you have some additional use-cases in mind, I'll be happy to address and incorporate those as well.
5. ?
I'd encourage you to read the doc. and bring up whatever you feel not covered, missing, incorrectly designed, etc. I am looking forward to your input. V.