Date: Mon, 27 Oct 2025 20:09:21 +0200
On Mon, Oct 27, 2025 at 7:57 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Mon, 27 Oct 2025 at 19:48, Andrei Zissu <andrziss_at_[hidden]> wrote:
> >
> > As it's still an MVP in C++26, the key decision to make for now is
> whether to use contracts at all. It's not that unfortunate having to wait 3
> more years for a riper product if the 1st minimal edition doesn't yet fit
> your use cases. Some of us though will be able to use them, and we should
> be allowed to.
>
> It's organizationally non-trivial to make a decision whether to use
> contracts at all. And perhaps it would be reasonable for early
> adopters
> of an experimental feature to use an experimental white paper
> implementation, instead of an IS implementation, when there's probably
> not going to be any availability difference between those.
>
How organizationally difficult can it be to just maintain the current
status quo for a little while longer if deemed appropriate? I would imagine
introducing a new major feature would be a much higher hurdle, even if it
absolutely does seem to fit all your use cases.
Early adopters would probably be mostly limited to academia and perhaps
some private experimentation and maybe some open source codebases. I don't
expect to see much code that pays actual salaries use a non-standard
feature, especially when the reason it's not yet in the standard would be
all this loud opposition.
>
> > I should have made an effort to come up with some proper pun for you
> calling over two decades of contract work (including half a decade of SG21)
> "as fast as possible", but I know I'm no match for your linguistic skills.
> 😉
>
> Time spent is not really a measure of cohesiveness or quality.
>
You were the one who brought speed into this conversation.
ville.voutilainen_at_[hidden]> wrote:
> On Mon, 27 Oct 2025 at 19:48, Andrei Zissu <andrziss_at_[hidden]> wrote:
> >
> > As it's still an MVP in C++26, the key decision to make for now is
> whether to use contracts at all. It's not that unfortunate having to wait 3
> more years for a riper product if the 1st minimal edition doesn't yet fit
> your use cases. Some of us though will be able to use them, and we should
> be allowed to.
>
> It's organizationally non-trivial to make a decision whether to use
> contracts at all. And perhaps it would be reasonable for early
> adopters
> of an experimental feature to use an experimental white paper
> implementation, instead of an IS implementation, when there's probably
> not going to be any availability difference between those.
>
How organizationally difficult can it be to just maintain the current
status quo for a little while longer if deemed appropriate? I would imagine
introducing a new major feature would be a much higher hurdle, even if it
absolutely does seem to fit all your use cases.
Early adopters would probably be mostly limited to academia and perhaps
some private experimentation and maybe some open source codebases. I don't
expect to see much code that pays actual salaries use a non-standard
feature, especially when the reason it's not yet in the standard would be
all this loud opposition.
>
> > I should have made an effort to come up with some proper pun for you
> calling over two decades of contract work (including half a decade of SG21)
> "as fast as possible", but I know I'm no match for your linguistic skills.
> 😉
>
> Time spent is not really a measure of cohesiveness or quality.
>
You were the one who brought speed into this conversation.
Received on 2025-10-27 18:09:34
