executors/executors

Issues

• Roblox

  #583 opened a year ago by Cody2live
  0

• Throwing exceptions from executors

  #582 opened 4 years ago by lucteo
  0

• receiver<> concept and usage in "2.2.3.5 execution::connect"

  #580 opened 4 years ago by lucteo
  4

• Should an executor be "nothrow" copy-constructible?

  #581 opened 4 years ago by lucteo
  0

• receiver_of should accept custom error types

  #579 opened 4 years ago by lucteo
  1

• Invalid indices in "2.2.12 Behavioral properties" (R14)

  #578 opened 4 years ago by lucteo
  0

• Suggested: move any_executor’s ‘prefer’ free function to be a member function

  #571 opened 4 years ago by inbal2l
  1

• Wrong parameter name in scheduler concept

  #572 opened 4 years ago by brycelelbach
  1

• Migrate the inheritance of receiver_invocation_error from the header synopsis to the class synopsis

  #573 opened 4 years ago by hatcat
  0

• Italicise unspecified items

  #574 opened 4 years ago by hatcat
  0

• Withdraw hyphens from exposition-only types unless there is precedent

  #575 opened 4 years ago by hatcat
  0

• Provide an annex of new identifiers being introduced

  #577 opened 4 years ago by hatcat
  0

• Provide examples of user code that relies on concepts

  #576 opened 4 years ago by hatcat
  0

• Align execution agent’s definition with the one in the standard

  #560 opened 4 years ago by inbal2l
  3

• Replace deleted functions overloads with constraints in any_executor’s constructors 'from other' and 'from executor'

  #562 opened 4 years ago by inbal2l
  0

• In any_executor’s operations section [2.2.11.2.5], replace ‘this function shall not participate in overload resolution’ with requires-clauses.

  #567 opened 4 years ago by inbal2l
  0

• Introduce R15 front matter

  #569 opened 4 years ago by jaredhoberock
  0

• Introduce R15 changelog

  #570 opened 4 years ago by jaredhoberock
  0

• Suggested: Add an explicit terms and design section

  #564 opened 4 years ago by inbal2l
  0

• Suggested: Add a (Short!) rationale for design choices

  #565 opened 4 years ago by inbal2l
  0

• Suggested: Explicitly specify the level of abstraction of the library

  #566 opened 4 years ago by inbal2l
  0

• 2.5.3 Schedule() method should be in the synopsis

  #533 opened 4 years ago by rarutyun
  0

• Remove 2.5.3.5

  #536 opened 4 years ago by rarutyun
  0

• Introduce the "behavioral properties" term of art

  #551 opened 4 years ago by rarutyun
  0

• Consider having the description of behavioral properties in one place use references to that

  #557 opened 4 years ago by rarutyun
  0

• 2.2.8. requires(E &&e) should be requires(const E &e)

  #538 opened 4 years ago by rarutyun
  2

• Suggested: Change ‘require’, ‘prefer’ and ‘query’ to functions taking forwarding reference, and add constraints.

  #559 opened 4 years ago by inbal2l
  0

• Consider moving 'Polymorphic wrapper' into a separate proposal

  #563 opened 4 years ago by inbal2l
  0

• Define minimal API for Properties of any_executor (for example: prefer_only)

  #561 opened 4 years ago by inbal2l
  0

• Make sure the exception_ptr is the the error type for the static_thread_pool sender

  #556 opened 4 years ago by rarutyun
  1

• Describe when and how submit/execute/other similar methods use allocator

  #555 opened 4 years ago by rarutyun
  1

• Investigate the possibility to simplify allocator_t property

  #554 opened 4 years ago by rarutyun
  0

• Consider alternative naming for outstanding_work_t property and nested properties for that

  #548 opened 4 years ago by rarutyun
  0

• Consider alternative naming for relationship_t property and nested properties for that

  #547 opened 4 years ago by rarutyun
  0

• Investigate the right default for relationship_t property

  #545 opened 4 years ago by rarutyun
  0

• [Duplicate of 549] Make sure P0443 does not refer to concept changing properties

  #558 opened 4 years ago by rarutyun
  0

• Consider consolidation of schedulers/senders type requirements on the P0443 level

  #553 opened 4 years ago by rarutyun
  0

• Investigate whether vendors can add their own properties via free functions but not member functions.

  #552 opened 4 years ago by rarutyun
  1

• Introduce the "Properties" term of art in P1393

  #550 opened 4 years ago by rarutyun
  0

• Make sure P0443 does not refer to concept changing properties anymore

  #549 opened 4 years ago by rarutyun
  1

• Provide stronger guarantees on outstanding_work.untracked

  #546 opened 4 years ago by rarutyun
  0

• Consider the third option for relationship_t property

  #544 opened 4 years ago by rarutyun
  0

• Investigate the right default for outstanding_work_t property

  #543 opened 4 years ago by rarutyun
  0

• Consider third option for outstanding_work_t property

  #542 opened 4 years ago by rarutyun
  0

• Investigate the necessity of operator== for static_thread_pool senders and for senders in general

  #540 opened 4 years ago by rarutyun
  0

• Consider whether to add a submit member function to the static_thread_pool sender type.

  #539 opened 4 years ago by rarutyun
  6

• Make sure that P0443 clearly states that receiver functions cannot be called until start is called

  #541 opened 4 years ago by rarutyun
  1

• Explore is operator!= should be explicitly listed

  #534 opened 4 years ago by rarutyun
  0

• Consider adding is_always_equal trait for executors/schedulers/senders

  #535 opened 4 years ago by rarutyun
  0

• Consider alternative name instead of schedule()

  #537 opened 4 years ago by rarutyun
  0