Range of enum type values
Timon Gehr
timon.gehr at gmx.ch
Sat Dec 28 13:33:25 UTC 2019
On 27.12.19 19:12, Johan Engelen wrote:
>
> [*]
> Let's not go off on a tangent,
It's not a tangent, it's a powerful tool to decide whether something has
any business being UB or not.
> but there is enough UB in D that I do not accept that @safe=="no UB" argument.
https://dlang.org/articles/safed.html
"In D, we expect the vast majority of programmers to operate within the
safe subset of D, which we call SafeD. The safety and the ease of use of
SafeD is comparable to Java—in fact Java programs can be
machine-translated into this safe subset of D. SafeD is easy to learn
and it keeps the programmers away from undefined behaviors. It is also
very efficient."
"[...] you are guaranteed not to encounter any undefined behavior."
https://dlang.org/spec/memory-safe-d.html
"Therefore, the safe subset of D consists only of programming language
features that are guaranteed to never result in memory corruption. See
this article for a rationale."
("this article" links to
https://dlang.org/articles/safed.html)
> One example that comes to mind is
> bitshifting by more than the operand bit width: "illegal" is what the
> spec says but that doesn't make sense for runtime shift values and, in
> practice, turns into UB at runtime. ;-)
What that means is not that UB is allowed in @safe code, but rather that
the spec hasn't been properly updated after @safe was introduced to
clarify what "illegal" means here. It should mean that the returned
value is arbitrary, not that the behavior of the entire program will be
arbitrary. I think Walter has said as much before, but I can't find the
post.
@safe is meant to imply no memory corruption. @safe implies no UB,
because UB can lead to any behavior, including memory corruption. UB
allows compilers to insert arbitrary code execution exploits. How can
you call that @safe?
More information about the Digitalmars-d
mailing list