Date: Fri, 12 Dec 2025 17:09:23 +0000
In wjf's proposal, he wanted to add a keyword to release the identifier and END THE LIFELINE so that we can reuse it as other variable, it is quite important to end early.
So all we are discussing today is based on this feature.
I think that if we lost all reference of a resource, we should free it. By this way, we need another feature to avoid "losing reference", so to be honest, changing a identifier makes a mess, the related features like adding const are more useful than the former. If you want to discuss these without the proposal, we can start a new thread and continue.
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, December 12, 2025 11:42:36 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_projectalpha.org>
Subject: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
Without the feature you have a guarantee that all parameters to a function and all previously defined variables have a lifetime at least as long as newly defined variables.
That means it is always okay to take references (and views) of those previously defined variables.
By just introducing that feature you give up those guarantees, even if the feature is not used.
That could lead to some coding guidelines to totally ban it.
Or could be a reason to mark those variables in a certain way.
Just saying, it is not a small thing. And more is not always better. You would also take away something.
Is ending the lifetime early an important part of the feature? If not, you could just keep the shadowing and let the lifetime end at the original location.
If it is important (to control the lifetime of variables in a random order), perhaps you could drop the reusing of the name.
Why is the combination needed/wanted? Are there special use cases? Or just because it would be easy to combine the syntax. I think each of the properties has to be discussed and sold separately. And then a good syntax can be found.
-----Ursprüngliche Nachricht-----
Von: SD SH via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Fr 12.12.2025 16:11
Betreff: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals_at_[hidden];
CC: SD SH <Z5515zwy_at_[hidden]>;
Yes, it is a wrong, I just want to say they will end after that line
to be precise:
} // float b ends there, then int a ends there
________________________________
发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月12日 22:51
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_[hidden]>
主题: Re: [std-proposals] 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
} // int a and float b ends there
they not just end at the same time, but in reverse order of starting the lifetime.
You can do
std::string s{"xyz"};
std::string_view v{s};
So all we are discussing today is based on this feature.
I think that if we lost all reference of a resource, we should free it. By this way, we need another feature to avoid "losing reference", so to be honest, changing a identifier makes a mess, the related features like adding const are more useful than the former. If you want to discuss these without the proposal, we can start a new thread and continue.
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, December 12, 2025 11:42:36 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_projectalpha.org>
Subject: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
Without the feature you have a guarantee that all parameters to a function and all previously defined variables have a lifetime at least as long as newly defined variables.
That means it is always okay to take references (and views) of those previously defined variables.
By just introducing that feature you give up those guarantees, even if the feature is not used.
That could lead to some coding guidelines to totally ban it.
Or could be a reason to mark those variables in a certain way.
Just saying, it is not a small thing. And more is not always better. You would also take away something.
Is ending the lifetime early an important part of the feature? If not, you could just keep the shadowing and let the lifetime end at the original location.
If it is important (to control the lifetime of variables in a random order), perhaps you could drop the reusing of the name.
Why is the combination needed/wanted? Are there special use cases? Or just because it would be easy to combine the syntax. I think each of the properties has to be discussed and sold separately. And then a good syntax can be found.
-----Ursprüngliche Nachricht-----
Von: SD SH via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Fr 12.12.2025 16:11
Betreff: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals_at_[hidden];
CC: SD SH <Z5515zwy_at_[hidden]>;
Yes, it is a wrong, I just want to say they will end after that line
to be precise:
} // float b ends there, then int a ends there
________________________________
发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月12日 22:51
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_[hidden]>
主题: Re: [std-proposals] 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
} // int a and float b ends there
they not just end at the same time, but in reverse order of starting the lifetime.
You can do
std::string s{"xyz"};
std::string_view v{s};
Received on 2025-12-12 17:09:29
