Показалось интересным: Can C++ be 10x Simpler & Safer? — Herb Sutter — CppCon 2022
Презентация от Герба Саттера о развитии синтаксиса для С++.

Здравствуйте, A13x, Вы писали:

A>Презентация от Герба Саттера о развитии синтаксиса для С++.
A>синтаксиса

Деградация какая-то.
Я не про сами предложения.
А про саму идею поменять... какой-то синтаксис, то есть на более важные вещи уже махнули рукой?

Здравствуйте, A13x, Вы писали:

A>Презентация от Герба Саттера о развитии синтаксиса для С++.
Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

Здравствуйте, Kernan, Вы писали:

K>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.

Здравствуйте, FR, Вы писали:

K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.

Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

Здравствуйте, so5team, Вы писали:

S>Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

Ну чукча не смотритель видео, но запомнилось почему-то что Саттер хотел сам С++ домучить

Здравствуйте, FR, Вы писали:

S>>Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

FR>Ну чукча не смотритель видео, но запомнилось почему-то что Саттер хотел сам С++ домучить

К сожалению, видео посмотреть придется, т.к. хороших описаний cpp2 в репозитории самого Саттера нет

Зато уже можно на godbolt поиграться.

Здравствуйте, A13x, Вы писали:

A>Показалось интересным: Can C++ be 10x Simpler & Safer? — Herb Sutter — CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

Вот оно что...
Вот откуда растут ноги всех этих Rust'ов...:

The Department of Commerce of the United States issued guidance that in response to this executive order: "... some programming languages such as C and C++ are not memory safe..." "... where possible do not use memory unsafe languages..."

— это где-то между 40-ой и 44-ой минутами из этой презентации.

До чего мы дожили!
Политики будут нам указывать на каком языке писать программы!
Маразм крепчал по всей планете
и в разных видах проявлял
ковидлы гиблые симптомы.

Здравствуйте, B0FEE664, Вы писали:

BFE>До чего мы дожили!
BFE>Политики будут нам указывать на каком языке писать программы!

Вообще это хорошая идея. Я бы ещё IPv4 запретил.

Здравствуйте, A13x, Вы писали:

A>Показалось интересным: Can C++ be 10x Simpler & Safer? — Herb Sutter — CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

не понял, почему вдруг он решил что тип в конце будет "simpler".
В остальном поддерживаю. Можно даже забить на новый синтаксис и ошибки не писать. Пусть компилятор пишет ворнинги ("В конце каждой улицы поставить турникеты. Да просто так. Пусть пока пропускают.").
Да и много вопросов остаются. Вот хорошо, добавили cpp2::is<T>. Но ведь аналогичные проверки были и раньше. Что поменялось?

o: std::optional<int> = {};
if(! (o is int))
    std::cout << o as int;

ушёл ли здесь UB? Если нет, то никакого решения memory safety я не вижу.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Kernan, Вы писали:

K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Всё равно придётся переписывать как Mozilla на Rust. Попытка усидеть на двух стульях приводит к печальный последствиям. Лучше бы думали как это спаять безболезненно, а народ перепишет потом. Всё равно делать нечего т.к. всё уже написано .
FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
Ну да, в итоге надо знать и TypeScriptС⁺⁺ и JavaScriptС++.

Здравствуйте, Kernan, Вы писали:

K>Зачем корёжить то, что и так нормально работает?

Не все работает нормально, увы.
Когда много лет живешь в обнимку с C++, то кажется, что нормально.
А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".

K>Зачем делать из С++ ещё один синтаксический go?

Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.

Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.

Может поиграются в cppfront и придумают как в C++ это перетащить с учетом выявленных проблем. Или докажут, что хрен редьки не слаще.

Здравствуйте, Kernan, Вы писали:

FR>>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
K>Всё равно придётся переписывать как Mozilla на Rust.

Как то она не особо в этом торопиться.

K>Попытка усидеть на двух стульях приводит к печальный последствиям. Лучше бы думали как это спаять безболезненно, а народ перепишет потом. Всё равно делать нечего т.к. всё уже написано .

Да ну вебщики вроде вполне живут с проектами где старый код и библиотеки на JavaScript, а все новое уже на TypeScript.
Я же не зря именно про TypeScript написал, из-за того что он именно безболезненно позволяет в обе стороны работать.

FR>>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
K>Ну да, в итоге надо знать и TypeScriptС⁺⁺ и JavaScriptС++.

Здравствуйте, so5team, Вы писали:

S>А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".
Приведи 5 проблем.

S>Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
Что с ними не так?

S>Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.
Склероз его замучил. Пусть вспомни как оно было.

Здравствуйте, FR, Вы писали:

FR>Как то она не особо в этом торопиться.
Ну так они нищие фриварники с 2% рынка браузеров.

FR>Да ну вебщики вроде вполне живут с проектами где старый код и библиотеки на JavaScript, а все новое уже на TypeScript.
Живут, но разве это жизнь?

FR>Я же не зря именно про TypeScript написал, из-за того что он именно безболезненно позволяет в обе стороны работать.
Но это не язык в языке как я понимаю.

Здравствуйте, Kernan, Вы писали:

S>>А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".
K>Приведи 5 проблем.

Почему 5, а не 10? Или не 3?

Ну, например, попробуйте объяснить новичкам в языке различия между:

template<typename T>
void f(T && v) {...}

template<typename T>
struct C {
  ...
  void f(T && v) {...}
};

или

const A & f();
...
auto a1 = f();
const auto & a2 = f();

или

struct S1 {
  void f();
};

struct S2 : S1 {...};

S2 s2;
s2.f();

class C1 {
public:
  void f();
};

class C2 : C1 {...};

C2 c2;
c2.f(); // Oops!

или почему для perfect forwarding нужно использовать std::forward<T>, а для перемещения std::move, но при этом сам std::move ничего не перемещает, более того, std::move можно применять и к константным ссылкам.

или почему в языке есть const_cast, static_cast, reinterpret_cast, но приведение в стиле Си не под запретом, но пользоваться им нельзя.

S>>Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
K>Что с ними не так?

Их слишком много и они не очевидны.

T();
T{};
T a;
T a();
T a{};
T a(x);
T a{x};
T a = x;
T a(x, y);
T a{x, y};

S>>Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.
K>Склероз его замучил. Пусть вспомни как оно было.

Это вы сейчас себя круче Саттера возомнили? Смело.
Позвольте нескромный вопрос: а вы вообще программировать умеете, хоть что-то про C++ знаете? Чем докажите?

У in и out есть несколько преимуществ, которые я не знаю как достичь в современном синтаксисе.

Момент первый.

Эффективность передачи значений. Например, если у меня есть:

template<typename T>
void f(const T & a) {...}

то насколько этот способ эффективен в зависимости от конкретного T? На конкретной 32-х битовой платформе, на конкретной 64-битовой? А через 10 лет? А через 20?

Тогда как:

template<typename T>
void f(in T a) {...}

может автоматически разруливаться компилятором либо в передачу по ссылке, либо в передачу по значению.

Ну и in T защищает вот от таких опечаток:

void f(const std::string v); // Хотели &, но забыли.

опечатки такие, к сожалению, имеют место быть.

Момент второй.

Если аргумент помечен как out, то компилятор может бить по рукам в ситуациях, когда у нас выходной параметр, но мы из него читаем еще до того, как что-то записали.

Здравствуйте, so5team, Вы писали:

S>Их слишком много и они не очевидны.

Ещё добавлю, что круглыми скобками нечаянно вместо переменной можно функцию объявить. Вот это вообще совсем неочевидная штука.

Здравствуйте, Nuzhny, Вы писали:

N>Ещё добавлю, что круглыми скобками нечаянно вместо переменной можно функцию объявить. Вот это вообще совсем неочевидная штука.

Такой пример там есть

Здравствуйте, so5team, Вы писали:


S>Момент первый.

S>Эффективность передачи значений. Например, если у меня есть:
S>

S>template<typename T>
S>void f(const T & a) {...}
S>

S>то насколько этот способ эффективен в зависимости от конкретного T? На конкретной 32-х битовой платформе, на конкретной 64-битовой? А через 10 лет? А через 20?
Это должен оптимизировать компилятор, а это константа при любой форме передачи.

S>Ну и in T защищает вот от таких опечаток:
S>

S>void f(const std::string v); // Хотели &, но забыли.
S>

S>опечатки такие, к сожалению, имеют место быть.
Это не опечатки, а нормальное использование оптимизирующего компилятора. Для программиста без разницы каким образом попала константа в функцию.

S>Момент второй.

S>Если аргумент помечен как out, то компилятор может бить по рукам в ситуациях, когда у нас выходной параметр, но мы из него читаем еще до того, как что-то записали.
Если это выходной параметр, то его можно только модифицировать в функции, остальное подозрительно. Если это inout, то тут ССЗБ. А вообще использование этой фигни заменяет возврат множественных значений.

Здравствуйте, A13x, Вы писали:

A>Показалось интересным: Can C++ be 10x Simpler &amp; Safer? &mdash; Herb Sutter &mdash; CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

Если из этого доклада выкинуть очевидные вещи освещённые в любом гайде, в gsl, то останется 20 процентов болезненного бреда индуцированного растом.