2 ms·

> But he never mentions any other benefits or justification for changing how it works. I read "it lets me write a program that has a data race", accompanied by

> But he never mentions any other benefits or justification for changing how it works. I read "it lets me write a program that has a data race", accompanied by a program that has a data race, as saying that the bug is that a language feature meant to provide mutual exclusion does not provide mutual exclusion. In a language one of whose main selling points is "you always get mutual exclusion". How is this not a bug? The benefit of changing this bug is that the guarantees Rusts makes to programmers are actually guaranteed.

khuey 9y ago
It's absolutely a legitimate bug.
dmix 9y ago
I was specifically referring to the 3rd comment on the Github issues page, not the first comment which mention a race condition which the eventual commit addressed > His third comment fits this category well. And even then I was only talking about the language he used, aka the justifications and rationale he proposed, which seemed entirely around being difficult to verify formally, rather than mentioning any real hypothetical 'bug', security flaw, or architectural downside.
- tom_mellior 9y ago
  Fair enough about the particular Github comment, but even there I think you are wrong. The architectural downside is being unable to understand a program you have written: "However, if the type does not have an explicit impl for Send/Sync, I don't know how to even figure this out -- I would have to chase all types (including safe ones, and across all abstractions) of all fields recursively and then check when they are Send/Sync... that's way too error-prone." This doesn't just talk about his particular proof tool being unable to understand this. It's about any Rust developer being unable to easily understand the types used by their programs, using only standard library constructs. (If anything, this should be easier for tools than for humans.)

khuey 9y ago

It's absolutely a legitimate bug.

dmix 9y ago

I was specifically referring to the 3rd comment on the Github issues page, not the first comment which mention a race condition which the eventual commit addressed > His third comment fits this category well. And even then I was only talking about the language he used, aka the justifications and rationale he proposed, which seemed entirely around being difficult to verify formally, rather than mentioning any real hypothetical 'bug', security flaw, or architectural downside.

tom_mellior 9y ago
Fair enough about the particular Github comment, but even there I think you are wrong. The architectural downside is being unable to understand a program you have written: "However, if the type does not have an explicit impl for Send/Sync, I don't know how to even figure this out -- I would have to chase all types (including safe ones, and across all abstractions) of all fields recursively and then check when they are Send/Sync... that's way too error-prone." This doesn't just talk about his particular proof tool being unable to understand this. It's about any Rust developer being unable to easily understand the types used by their programs, using only standard library constructs. (If anything, this should be easier for tools than for humans.)