> Ville Voutilainen :

The idea generalizes:
> 1) ..while the result of an operation with particular characteristic
> $foo on an object X is within its lifetime..
> 2) ..operations with another particular characteristic $bar on X are
> ill-formed
> or the opposite,
> 1) ..unless an operation with characteristic $foo has been performed
> on an object X and the result is within its lifetime..
> 2) ..operations with a particular characteristic $bar on X are ill-formed
> An example of this would be "unless you hold a lock on X, you can't
> invoke its non-thread-safe modifiers
> (thread-safe modifiers are fine)".


I think typestates + contracts on functions signatures is what you want?
Unfortunately I do not know of any language that combines these two
features, although I have seen a couple of research papers which follow
this approach to prove the soundness of C programs (i would have sent them,
but i can't find them at the moment, sorry). Rust had support for
typestates early on, AFAIK they had plans to use them inside a contract
language feature, they were eventually removed as - i think - very few
people used them, and most of these use cases could be covered by Rust
linear type system.

Le dim. 25 avr. 2021 à 14:40, Thomas Neumann via Std-Proposals <
std-proposals_at_[hidden]> a écrit :

> > At least from a PR point of view, it seems that some important companies
> > (some of the heaviest C++ users), are thinking that a language that
> > offers memory safety is worth trying, even to replace code that
> > previously was written in C++.
> >
> > Other resource types are important, but maybe their impact in Security
> > is not as big. Apart from personal dislikes like in the Linux kernel, it
> > seems that memory safety promises are big enough to invest a
> > considerable effort in alternative languages for currently C++ codebases.
>
> I agree, and I am pretty confident that we could offer memory safety
> guarantees for code that asks for it with relatively minor changes,
> potentially even fully attribute driven, and without affecting existing
> code that does not want these checks.
>
> I still haven't found a good solution yet for "destructive" moves, i.e.
> moves where the source is completely gone and no destructor should be
> called. But we can probably find a solution for this, too. I just did
> not want to spend more time on this until it is clear that there is at
> least some interest in this feature.
>
> Best
>
> Thomas
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>