Using Azure Pipelines badge instead of the Travis-ci and Appveyor badges.

Thanks, the suggestion is a nice improvement. About "not guaranteed to provide useful functionality", I suspect that that additional strengthening wouldn't help much if we don't also define "useful functionality", so I think what we have now will do the job.

Paragraph 7 of [dcl.array] (https://eel.is/c++draft/dcl.array#7) states:

In addition to declarations in which an incomplete object type is allowed, an array bound may be omitted in some cases in the declaration of a function parameter ([dcl.fct]). An array bound may also be omitted when an object (but not a non-static data member) of array type is initialized and the declarator is followed by an initializer ([dcl.init], [class.mem], [expr.type.conv], [expr.new]). In these cases, the array bound is calculated from the number of initial elements (say, N) supplied ([dcl.init.aggr]), and the type of the array is “array of N U”.

The wording "an array bound may be omitted in some cases in the declaration of a function parameter", among other changes, was added by the resolution to CWG619.

Actually, the highlighted part ("in some cases") is the only difference between the proposed resolution in February of 2010 compared to the proposed resolution in March of 2010.

I believe that the only cases in which it was not allowed (at that time) to omit array bounds in the declaration of a function parameter were specified by [dcl.fct] p.8, which stated (in N3035, published in 2010):

If the type of a parameter includes a type of the form “pointer to array of unknown bound of T” or “reference to array of unknown bound of T,” the program is ill-formed. Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions. Types shall not be defined in return or parameter types. The type of a parameter or the return type for a function definition shall not be an incomplete class type (possibly cv-qualified) unless the function definition is nested within the member-specification for that class (including definitions in nested classes defined within the class).

However, the highlighted part of [dcl.fct] p.8 (forbidding pointers or references to arrays of unknown bound in the type of a parameter) was removed by the resolution to CWG393.

I do not know any cases in which, by the current specification, one cannot use arrays of unknown bound in the type of a function parameter. Are there any such cases that I am overlooking?

Done.

Done.

That's nice, thanks. That's exactly the kind of comment I am looking for: we don't just want to change the bad words away mechanically, but ideally find nice ways to say something equivalent that avoids them.

I agree that the existing wording is already questionable, so let's keep this entire change out and have it reviewed by the wording group.

As long as \nontermdef is only used for the symbol being defined, then that'd work just fine.

However, it is possible for \tcode{f} not to be called at all,

This feels a little clearer and less awkward:

If the clock is not synchronized with a steady clock, e.g., a CPU time clock, these
timeouts can fail to provide useful functionality.

Something like "...these timeouts are not guaranteed to provide..." would be even better, but I'm not sure if that passes ISO muster.

No comma or "a" here.

Isn't the "may" here also problematic, since we aren't giving permission to failure but for it?

No comma here.

I might say, slightly more directly, "then it is possible that the end iterator is unreachable".

@jensmaurer's suggestion sounds somewhat more structured -- what do you think? That way people don't have to remember to type colons at all.

@opensdh: Could you perhaps take a look at the filesystem changes?

@geoffromer: Could you perhaps take a look at the atomics and threads changes?

Thank you!

These changes editorially remove the words "could" and "might".

Please review this change carefully with the following goals:

Flag anything that seems even remotely non-editorial, e.g. even if the explanation provided by a Note becomes less useful or (more) misleading. Also flag anything that could conceivably be worded better by a wider review. I would like all remaining instances of "could" and "might" to be reviewed by CWG/LWG, so please don't hold back on rejecting anything at this point.

We could make the colon an “active character.” This would allow you to just type an unadorned colon in the source (within the BNF environments) and LaTeX would interpret it as a macro that expands to \textnormal{:} (or similar).

@sunnychatterjee surely T would have to be standard layout, right? The versions of these function I have written throw an exception if the span is too smal for T, since your overload is noexcept, I imagine you return nullptr in that case, is that right?

There's also the issue of alignment, either alignof(T) would have to be 1, or some runtime check would have to be made to ensure correct alignment of the span pointer.

At least that was my understanding (probably also gsl::byte on c++14 systems and realistically, someone will want to have it for unsigned char too).

@amaroker That's true, and I'm still not certain that there's a need to remove that check inside .get() -- because that one is only a performance improvement on some runs, and either of the other two changes by themselves also gives similar benefit.

I'm still investigating, but on some further experiments I ran today it does appear the extra check is free even in get() where it is redundant as long as every write to the pointer is checked. I'm now investigating whether it remains free even with a bit of additional complication in the check logic -- specifically I'm experimenting with calling a customizable violation handler to resolve a few of the other open issues.

Thanks again for the repro!

Thanks @hsutter for sharing your observations!

The performance improvements that you suggest would be satisfying.

I agree that there's no need to assert on each read (hence the removal) because the invariant has already been validated when the pointer was set in the constructor.

But I'm still curious. You previously suggested that not null test is to be considered free. But in this example, that's only true in the constructor. So, what really surprises me is that the assertion (not-null test without __builtin_expect) has different performance impact in a constructor and in a member function. Any thoughts on that?

Ah yes if the new member is only on that specialization, it wouldn't be needed.

I think so yes, absolutely. However, when exactly would that be necessary? No matter what T is, my_span (or rather the return type ofsubspanin this example would always be of the concrete typegsl::spanstd::byteand thus the addtitiontemplate` should not be necessary no?