On Thursday, 21 July 2016 at 16:39:18 UTC, Andrew Godfrey wrote:
> You seem to be assuming that everyone already agrees on which set of changes should be made to the language. (Otherwise, how could you expect anyone to "officially back" a side project?)
>
> But agreeing on which changes to make and, especially, which to NOT make, is the hard part. And it's why you'd need a lot of planning & discussion up front (if any of us non-founders wanted to participate). And many people don't understand this, which IMO is behind a lot of hard feelings in the forums.

The basic idea would be not to radically change the language, but come down to a clean core and build the existing useful concepts on top of that core.

A year ago or so it was claimed that the compiler core would would be refactored and before that it was asked in the forum if current users would prefer non-breaking changes or a clean up. My impression was that the majority was willing to take some breaking changes in order to get a more streamlined experience.

Anyway, it is summertime, maybe we can discuss this later in the autumn ;-).

(I don't have time to follow the forums.)

On Monday, 11 July 2016 at 18:57:51 UTC, deadalnix wrote:
> Alright, but keep in mind that is an example, not the actual problem I'm talking about. There are many reasonable way to make the example above safe: disallow dereferencing pointers from unknown source, do a bound check on .ptr, disallow .ptr altogether and much more.
>
> The root problem is that "@safe guarantee memory safety and if it doesn't it is a bug" provides no information as to what is the bug here and no actionable items as to how to fix it, or even as to what needs fixing.

Saw it on reddit: how rust manages safety bugs: https://www.reddit.com/r/programming/comments/4vto4r/inside_the_fastest_font_renderer_in_the_world/d61ltp8

On 15.07.2016 22:29, Walter Bright wrote:
> On 7/15/2016 12:55 PM, Jack Stouffer wrote:
>> On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote:
>>> 4. making use of asserts to provide information to the optimizer
>>
>> Do dmd/ldc/gdc actually do this?
>
> dmd doesn't. I don't know about other compilers.
>
> The point is it's possible because C++ doesn't have asserts. C++ has an
> assert macro, defined to be the same as in C. The definition of assert
> in C is such that it is turned on/off with the NDEBUG macro, meaning
> that when it is off, the compiler CANNOT derive any semantic information
> from it, because it effectively vanishes from the code.
>
> In contrast, assert in D is a keyword and has a semantic production.
> Even if generating code for the assert is disabled with the -release
> switch, the semantics of it remain and are available to the optimizer.
>
> C++ didn't repeat that mistake with 'static_assert' (another feature
> copied from D), but static assert doesn't help the optimizer.

Just to be explicit about this: What kind of "help" do you want to be provided to the optimizer?
I.e., why didn't you say: "Failing assertions are undefined behavior with the -release switch."