tvaneerd / isocpp Goto Github PK

The table needs to separate cast from constructor - the answers imply different results. ie not same thing -> explicit constructor, but does NOT imply explicit cast.

So two tables? split table? Not a table? A tree? A ...?

When is it OK for assignment to be implicit but construction explicit?
Howard and I both think "not usually, but sometimes", but have no hard rules.

eg. zoned_time = local_time sets the local-time portion of a zoned_time. Is that OK?

StringId isn't convertible from string (to avoid accidental passing a string when you want an ID)
but StringId = string seems like there is intent, and it is not accidental.

Whereas milliseconds = int is probably too dangerous.

For units like milliseconds, the int represents a measure in some unit - the question is "is it the right unit"

For StringId = string, there is only one meaning - set the internal string. Could the string be in the wrong "unit"? Less likely?

zoned_time = local_time still seems scary to me - there are two (equally) valid meanings - just set the time portion of zoned_time, or convert from that time in the local time zone into the simultaneous time in the zoned_time's time zone.

Going Towards a More General Looping Mechanism

Document number: DXXXXR0
Date: 20XX-MM-DD
Audience: EWG
Reply-to: Tony Van Eerd. tt at forecode.com

Summary

Current looping mechanisms (forloops, while and do...while loops)
are great - in their niche uses;
but they are often found wanting, resulting in awkward constructs.
In particular, in a few cases it is impossible to NOT repeat yourself (ie a violation of DRY) or to be concise, using those mechanisms.

Looking at how all these mechanisms work, we can refactor them into a single, more general, control flow mechanism.
In fact, it could replace all the other keywords with this single mechanism!

(Note, for the sake of backwards compatibility, we do not recommend deprecation at this time.
If the new style is widely adopted - as we expect it will - we can deprecate the old keywords
when common coding practices show they have fallen out of favour.)

bool res = false;

for(int retry = 10;  !res && retry;  retry--)
{
    res = askHardware(question, &num);
    // don't know why it succeeds while failing,
    // but it does.  :-(
    // Sadly, re-asking is the solution.
    if (res && num == 0) {
        sleepHack(200);
        continue;
    }
}
return res;

// pre-conditions
bool res; // undetermined
int retry = 10;

// invariant
// retry >= 0

// post-conditions
auto post_condition = bool [res, num, retry](){
  res && num == 0 || retry == 0 
}
do{
  int num;
  sleepHack(200);
  res = askHardware(question, &num);
  --retry; // advances state - must terminate
}
while(! post_condition());
return res;

More Elucidating Examples

... show more problematic uses of current control flow, compared against new mechanism

Proof of Replacement

... show before/after table replacing each of { for, while and do...while }

Technical Details or Preliminary Wording, Etc

Label statements, goto statement. Etc.

Further Work

Initial results suggest a "computed goto" could also replace if and switch statements - thus completely replacing all control flow mechanisms with a single keyword. The committee should give me a kidney.

Upon reading your document, https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md, I found one missing argument which is the main reason I am looking into observer_ptr, namely the technique called strong typing (see, e.g., the blogpost at https://www.fluentcpp.com/2016/12/05/named-constructors/). In my case, I have two variables with vastly different meaning (like double radius and double diameter in blogpost), but with the same pointer type (say double *radius_handle and double *diameter_handle for the sake of example, though you may come up with something better). To distinguish them (from a function overloading perspective) I plan on wrapping them in distinct class types as described in the blogpost (e.g., a class called RadiusHandle to hold double* radius_handle as member). Rather than just boxing/unboxing at every relevant function as the blogpost suggests, I had the idea to simply use observer_ptr as the base class for my strong types, and just use those strong types directly as they are via the observer_ptr functionality. No need to box and unbox. In fact, in this scenario, only owners needs to see the raw pointers (whose types can't be distinguished), and all observers can just use the strong types.

If you want, you can use this argument in favor of standardizing observer_ptr. Otherwise, just close this documentation request.

One alternative to be added to the list: std::address.

This is likely contentious, but in the guidelines table, should how the conversion interacts with emplacement in containers (and optional and variant) be considered for explicit vs named conversion function?
i.e.

vector<nanoseconds> v;
v.emplace_back(5);

Is that a desirable compilation for your class?

As a function param,

T const & is probably my favourite;
T * pointer is OK, but has the various downsides mentioned in this thread:
    - allows ++, --, and [ ] even when it shouldn't
    - allows derived/base conversions (and then more ++/--)
    - opens up questions about ownership (in many codebases)
    - requires unnecessary calls to .get() at call site (noisy, and again opening up questions about ownership)
    - < is not a total order
    - conversion to void *
    - etc? ie allows reinterpret_cast?

It should probably be mentioned that the copy/move ctor should never be explicit.

And by 'never' does mean 'rarely' (as usual) or does it really mean never?

A heavy class, ie an Image class should probably not have a copy-ctor.
Typically a copy() or clone() function makes it more clear than there is no free lunch.
Would an explicit copy-ctor actually make sense here?