home.social

#wg21 — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #wg21, aggregated by home.social.

  1. @mhoemmen mdspan feature request 😉:
    Allow mdspan::operator[] with one argument less than rank.
    Mandates/Constraints: The resulting range is contiguous in memory.
    Returns: A span (of static extent, if possible).

    Then I can use std::simd CTAD from range:
    simd::basic_vec(B[k], simd::flag_aligned);

    instead of:
    simd::unchecked_load<simd::vec<T, N>>(&B[k, 0], &B[k, N-1], simd::flag_aligned);

    The former is not only simpler but also safer.

    #WG21 #cpp29

  2. On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
    And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

  3. On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
    And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

  4. On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
    And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

  5. On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
    And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

  6. On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
    And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

  7. What's the constexpr-if equivalent to `condition ? x : y`? As far as I know we only have `[&] { if constexpr (condition) return x; else return y; }()`. I hate it.

    #cpp #cplusplus #WG21

  8. Can we fix the following inconsistency in #CPlusPlus: compiler-explorer.com/z/qsYeTn? A conversion operator is sufficient to call wrapped function pointers. But it does not work for wrapped callable objects. And that's even though `wrapper` in the above example has the callable type in its associated namespaces (ADL). ADL was introduced to make operators work. I patched my #GCC to make it work and I like it.

    #WG21 #cpp29 #cpp

  9. Last week meant survival mode. Attending the #WG21 meeting in Kona, Hawaii *virtually* meant Zoom sessions from 19:00–04:00. With family in the house, some of them sick, my priority was 1. not getting sick 2. getting the work done. So no 🏊🚴🏃 last week.

    1/1

    #weightlifting #traininglog

  10. Immediate escalating expressions promote constexpr functions to immediate functions. 👍 Now, can I get a partially promoted half-immediate function instead? 😢

    #wg21 #cpp26

  11. I read open-std.org/JTC1/SC22/WG21/do "Poor Functions" last night. I jumped for joy! 😆 Finally, I had words for what I was thinking all this time. This __local_ctx idea puts into words what I wanted to say with regard to #FunctionMultiVersioning (gcc.gnu.org/wiki/FunctionMulti). I need to be able to reflect on those attributes in order to make SIMD types and functions behave correctly in the context of FMV. __local_ctx producing a std::meta::info sounds like the solution!

    #WG21 #cpp26 #GCC

  12. There's resistance against using the same name in a namespace and a type inside that namespace. Why? What is the actual problem with this code? Is the 'foo::foo' looking too much like a constructor definition (in that context)? Isn't it great how the call to 'bar' has a clear relation to 'foo'?
    Why is it considered bad practice that shouldn't pass code review?

    #cpp #cplusplus #WG21 #cpp26 #namingThingsIsHard

  13. @dneto 🙂 that phrasing/song was unknown to me.
    I'd like to learn more about the details of non-IEEE fp. I know about targets missing support for evaluating subnormals, while still using IEEE representation. I need a better understanding here because there's a push in #WG21 (#cpp committee) to rely more on IEEE fp. And also the big question of compile-time vs. run-time behavior of fp.

  14. @foonathan

    “We should also be clear that the work on profiles does appear to have extremely strong support in WG21.”

    This is, to a significant extent, because people who feel that profiles are a complete waste of time have given up on #WG21, or have even given up on C++.

    #Cplusplus

  15. @vitaut Your “path_view: a design that took a wrong turn” paper (wg21.link/p2645r0) is excellent! Thanks for writing it. #cplusplus #wg21

  16. std::execution принят в C++26 — пора знакомиться

    Единый фреймворк асинхронности и параллелизма, возможность делить вычислительные ресурсы разными кодовыми базами без сложной интеграции, простота использования и гибкость - все это то, чего в C++ никогда не было. В конце июня стандартный комитет одобрил включение std::execution ( P2300 ) в C++26 . Это пропозал, который призван решить вышеуказанные проблемы. Давайте разбираться!

    habr.com/ru/articles/842316/

    #c++ #c++26 #executors #wg21 #эволюция_языка #программирование

  17. Нативная рефлексия в C++ уже близко

    Почему в 2024 году нам приходится писать каст енума к строке вручную, для каждого кастомного типа нужна своя функция логирования, а биндинги к C++ библиотеке требуют кучу повторяющегося кода? Если Вы задавались этими, или подобными вопросами, то у меня для вас хорошая новость - скоро эти проблемы будут решены. И что самое приятное - на уровне языка, а не нестандартным фреймворком. Сегодня рассматриваем пропозалы рефлексии, которые с большОй вероятностью попадут в следующий стандарт - C++26 .

    habr.com/ru/articles/824840/

    #С++ #с++26 #рефлексия #wg21 #эволюция_языка #программирование

  18. How do you write a condition (C++23) that is partially constexpr-if and in part a run-time branch? If I nest constexpr-if and if, I cannot avoid duplication of the else branch. If I remove the constexpr keyword, the code is ill-formed for some specializations. 😩 I need a branch that mixes constexpr and runtime conditions! #cpp #wg21

  19. I hope this post gets the attention of at least a few ISO C++ "std-proposals" subscribers.

    Does std-proposals subscription really mail every subscriber their pwd, in clear, *every month*? Why?

    I imagine historical reasons like forgetful subscribers back when online interactions were not routine, but this day and age? May be the page is old and this is no longer practiced? 🤔

    Just curious. Don't mean to question anything. ✌️

    EDIT: Answered 🙏

    lists.isocpp.org/mailman/listi #cpp #isoCpp #wg21 #infosec

  20. @root42 open-std.org/jtc1/sc22/wg21/do

    I was involved in reviewing this paper and 100% agree with the decision to deprecate and remove <codecvt>. The question is not, "Why was this added?" but should be, "Why was this added in the first place?"

    3/3

    #cpp #unicode #wg21

  21. @root42 "Reports from users in the field indicated repeated attempts to use this facility, as a part of the standard library bearing the most useful name suggested this should be our best practice, only to repeatedly fail for subtle reasons in our underspecification, leading to many home-grown solutions instead after much wasted time."

    2/3

    #cpp #unicode #wg21

  22. @root42 "As the Unicode standard and security experts point out, ill-formed UTF can be and has been used as an attack vector. Yet the <codecvt> facets don’t provide the safe forms of error handling as their defaults, and it is far to
    hard to use them in a safe way."

    1/3

    #cpp #unicode #wg21

  23. @timur_audio Excellent. My view was always, "Be courageous and introduce keywords!" and I'm glad that we'll get a contracts syntax that matches the other syntax around function declarations. Thanks for all your hard work.

    I'd like to show this to my colleagues. Do you know when there will be an implementation available via Compiler Explorer?

    #cpp #wg21

  24. "This talk is an invitation to embark on a journey to solve one of the most naive yet insanely convoluted open question in #software architecture: the problem of unit systems and physical quantities. As surprising as it may seem, in 2023, there is still no software library available in any of the most common programming languages that covers the issue in its full complexity including its myriad of edge cases. In the context of a standardization effort within the #cpp programming language committee #WG21 on the topic of units this talk constitutes an attempt to reach out to the #appliedcategorytheory community in order to approach the subject from a new angle.

    Throughout the presentation, a particular attention will be put on the underlying reasons behind the emerging complexity of the subject and why applied category theory may be key to disentangle this apparent complexity. This will be illustrated by concrete applications in computational #physics and metrology, including particularly pathological cases that will put into question the very notion of what a unit is. Exploring conceptual boundaries through edge cases will help putting constraints on the mathematical structures that may be used to abstract the problem. Beyond the mere scope of being able to standardize a unit systems software library, the challenge raised in this talk represents a gateway to deep questions about physics, its language, its structure, and how to translate it into #typetheory. It also constitutes a perfect playground for applied category theory, going from a naive and well-framed question to an interdisciplinary open problem at the intersection of physics, computer science, and mathematics with broad impacts for programming languages and international standards."

    youtube.com/watch?v=6Fc-mjFMSr

  25. @fugueish As an actual member of #WG21 my reaction to that paper was, "I'm not just disappointed, I'm angry." #cpp

  26. @blinkygal NaN is unordered with respect to other floating point values, so I don't think it makes sense for the #cpp IS to mandate a particular result from ranges::max().

    Does it overly constrain implementers to require that compile time and runtime UB from floating point operations are congruent? I tried arguing for congruence in #WG21 but was outvoted.

    What if one filed an implementation bug? Not sure what the response would be.

  27. #Cpp #CppVarna #WG21: Friday notes

    I hung out in EWG all day.

    - P2884r0, P2883r0: We didn't agree to make offsetof and assert into keywords
    - We enjoyed a "7 min presentation" (actually 45 mins) on why functions with narrow contracts should not be noexcept; more to come in Kona
    - P2814r0, P2786r1: Absolutely no meeting of minds on trivial relocatability; EWG seems to want a full, general solution to relocation. But we discouraged everyone who proposed relocation features over the last 10 yrs…