| |
 | Posted by Bruce Carneal in reply to Ola Fosheim Grøstad | Permalink Reply |
|
Bruce Carneal 
Posted in reply to Ola Fosheim Grøstad
| On Wednesday, 16 June 2021 at 23:15:19 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 16 June 2021 at 22:54:51 UTC, Bruce Carneal wrote:
>> We all work to isolate dependencies, safety related and otherwise, so that we can reason about the whole with more confidence. Whenever we introduce something that impedes our ability to "treeify" dependencies, something that makes analysis more of a graph analysis than a tree analysis, we've done something that has made maintenance and code-reuse more difficult.
>
> Well, but the problem is at a more fundamental level...
Fundamental problems sometimes admit incremental improvements towards resolution. I'm more disposed to improvement-through-simplifying-but-possibly-large-rewrites than incremental change but in this case I'd go with incremental.
>
> For instance, if I write a program with GC turned off as an invariant. Then I might audit code that packs information into lower bits of addresses in pointers values as safe. Then some other guy takes over the code base and decides to turn on the GC. Well, effectively the program is broken at a global level, because the actual scope of @trusted that we can be certain of is the whole program! :-D
>
Sure, we have responsibility for the whole program. Anything that lets us confidently subdivide that problem is welcome.
>>At the language level we can't stop programmers from writing
>> code with nasty dependencies but we can make it easier to write code with fewer entanglements.
>
> As long as people continue to modify, refactor, redesign and change invariants then you need something more explicit.
I disagree. I believe that more general mechanisms can help that do not preclude the finer granularity mechanisms which you advocate (and which I am interested in).
>
> For instance if my unsafe region had been marked with a tag that said pointer-value-manipulation, and you have a timestamp on it, and you have ...
I believe providing the compiler with more information can be a very good thing, perhaps worthy of another thread.
>
>> Perhaps I misunderstand you but I'd say it's good for a lot. As a contrasting exercise one can think about what would happen if @safe/@trusted/@system became compiler noops starting tomorrow and forevermore.
>
> No, @safe does something, but you cannot know what the scope of @trusted should be, because even global invariants can change. So you might as well do what other languages do and just put an "unsafe" compiler-bypass-checking-silencer on the offending statement/expression.
Yes, @trusted works within a broader framework, a *manually managed hence dangerous* framework. A practical path forward is to improve the compilers ability to check things and localize/minimize the unchecked. As far as how the programmer deals with all the rest, well, I'd say we're back to "best practices" and "convention".
We all want the language/compiler to do more on the safety front, at least if improvements come at very little coding inconvenience, but something like an @trusted transition zone will be needed at the, evolving programmer defined, boundary between machine checkable and "you're on your own".
> ...
>> Yes, I think things can be made better but there's already, to my way of thinking at least, a lot of value.
>
> Ok, but it doesn't do anything more than a comment.
In line with my comments both above and below, I disagree.
>
>> I think that finer granularity/specificity might be useful, particularly if can improve basic readability/nesting.
>
>
> For it to work, you need to list all the invariants that the audit of the unsafe region makes assumptions about.
>
> With such a list you could actually trigger warnings about unsafe regions when the invariants change.
Yes. The compiler will need enough information to act.
>
> Scope is not really meaningful. The scope of the unsafe statement is unknown, because the code base is changing.
If I understand your meaning here, I disagree. I think @safe/@trusted is very useful, essential even, in code bases that are changing. It is a demarcation tool that lets us carve out ever larger safe areas.
|