[Bug c++/110872] New: coroutine postcondition is not evaluated

2023-08-01 Thread akrzemi1 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872

Bug ID: 110872
   Summary: coroutine postcondition is not evaluated
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

Created attachment 55673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55673=edit
demo program

A postconditon declared on a coroutine should be evaluated when the coroutine
is invoked and returns to the caller. But it isn't as per the following
Compiler Explorer link.

https://godbolt.org/z/48fh3f34j

The expectation is enforced by the fact that the compiler allows mentioning the
return type of the coroutine declaration:

```
template 
struct generator
{
// ...
bool is_valid() { return false; }
};

generator val(int v) 
[[post g: g.is_valid()]]
{
co_yield v;
}
```

Generally, I would expect that preconditions and postconditions on coroutines
should work the same as if the call to the coroutine was wrapped in a
forwarding function containing the preconditions and postconditions:

```
awaitable f1(int i)  // coroutine
  [[pre: p(i)]]
  [[post r: q(r)]];

awaitable f2(int i); // coroutine

awaitable ff2(int i)
  [[pre: p(i)]]
  [[post r: q(r)]];
{
  return f2(i);
}

void caller()
{
  f1(1);  // these two calls should have analogous
  ff2(1); // precondition and postcondition semantics
}
```

[Bug c++/110871] New: coroutine precondition should be evaluated before the initial suspend

2023-08-01 Thread akrzemi1 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871

Bug ID: 110871
   Summary: coroutine precondition should be evaluated before the
initial suspend
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

Created attachment 55672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55672=edit
Sample program illustrating the bug

When I declare a precondition on a coroutine, it is not evaluated when the
corresponding promise type performs the initial suspend.

While "C++20 contracts" or the "Contracts MVP"
(https://isocpp.org/files/papers/P2388R4.html) never mention how this should
work, the intuition dictates that the preconditions protect against the usage
of the incorrect combination of function parameters.

Function parameters of a coroutine may be used before the initial suspend to
initialize the promise object (when it provides a variadic constructor). The
coroutine precondition should be evaluated before this initialization,
therefore before the initial suspend.

Also, this follows from the rule of thumb that implementations should have
freedom to check the precondition either in the caller or in the callee and
either choice should not affect the program semantics. 

The following Compiler Explorer example illustrtes the issue. "Disaster!"
should  never be printed:

https://godbolt.org/z/fxMjT4vfx

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

2020-09-28 Thread akrzemi1 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830

--- Comment #16 from Andrzej Krzemienski  ---
Oh, I see. The above requirement applies only to chapter Algorithms library.
Not Iterators library. Sorry.

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

2020-09-28 Thread akrzemi1 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830

--- Comment #15 from Andrzej Krzemienski  ---
How come? 
[algorithms.requirements], paragraph 4, bullet 5
(http://eel.is/c++draft/algorithms#requirements-4.5) says:

If an algorithm's template parameter is named BidirectionalIterator,
BidirectionalIterator1, or BidirectionalIterator2, the template argument shall
meet the Cpp17BidirectionalIterator requirements