On 6/10/2019 5:49 PM, Manu wrote:
> Well it's an unsatisfying or incomplete definition then if it allows
> for something so obviously unsafe (in english terms) to be considered
> perfectly fine.

Memory safety is not an incomplete concept. It's objectively defined.

> in english terms

We don't use conversational english when discussing mathematics (and this is a branch of mathematics) precisely because conversational english is imprecise, vague, and people impute their own meanings into it. We cannot have a conversation about programming languages unless we have a common understanding of what the jargon means.

Here is what memory safety means:

"Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers."

  -- https://en.wikipedia.org/wiki/Memory_safety

D defines @safe as "memory safe". It does not define it as "no undefined behavior".

D does fall short of that goal, because it doesn't thoroughly track allocated memory pointers. But that has nothing to do with undefined values for integers.

On Tuesday, 11 June 2019 at 01:42:37 UTC, SonicFreak94 wrote:
> On Tuesday, 11 June 2019 at 01:33:58 UTC, Exil wrote:
>> You can do this with structs and alias this now. I also doubt code injection is something a language should consider for its use cases. It is only really useful for a niche.
>
> Convenient, with the caveat that one must add that as a field manually and then add another line to alias it. Two D lines for the functionality of one in C++, just so that I can share members...

So you are using C++ instead of D in some instances cause you don't want to write one extra line of code? If you put it in a mixin then it is only 1 line of code. I wouldn't split my codebase like that just for one line of code, but I guess that's your decision to make.

On 11.06.19 13:03, Walter Bright wrote:
> D defines @safe as "memory safe". It does not define it as "no undefined behavior".

The spec very much defines @safe as "no undefined behavior".

<https://dlang.org/spec/function.html#function-safety>: "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior."

On Tue, Jun 11, 2019 at 4:06 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 6/10/2019 5:49 PM, Manu wrote:
> > Well it's an unsatisfying or incomplete definition then if it allows for something so obviously unsafe (in english terms) to be considered perfectly fine.
>
> Memory safety is not an incomplete concept. It's objectively defined.
>
>  > in english terms
>
> We don't use conversational english when discussing mathematics (and this is a branch of mathematics) precisely because conversational english is imprecise, vague, and people impute their own meanings into it. We cannot have a conversation about programming languages unless we have a common understanding of what the jargon means.
>
> Here is what memory safety means:
>
> "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers."
>
>    -- https://en.wikipedia.org/wiki/Memory_safety
>
> D defines @safe as "memory safe". It does not define it as "no undefined behavior".
>
> D does fall short of that goal, because it doesn't thoroughly track allocated memory pointers. But that has nothing to do with undefined values for integers.

You've missed my entire point. I understand memory safety is a thing,
I'm saying I don't care for @safe defined that narrowly. Common sense
would suggest that a "safe" function would alarm you to a blindingly
obvious crash, and I don't care that that crash is specifically a
memory safety violation or not. You can argue semantics, but nobody
that's not a language lawyer who hangs out on forums like this would
expect that.
Low-level mischief (like uninitialised data with manually handled
construction) is plainly not safe, it's low-level hacks and MUST be
treated with absolute care. I should be able to find all instances of
code like that when searching for @system or @trusted, because
probability of mistakes is high.
Anyway, this is off-topic. I also don't tend to use @safe, although I
like the idea in principle.

Quick question, Manu. What are referring to when you say "uninitialized data"? Do you mean:

int n = void;
n++; //Undefined behaviour

Struct S { int getVal() { return 1; } }
S s = void;
s.getVal(); //Undefined behaviour

Or do you mean:

int n;
n++;

S s;
s.getVal();

On Tue, Jun 11, 2019 at 1:25 PM Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Quick question, Manu. What are referring to when you say "uninitialized data"? Do you mean:
>
> int n = void;
> n++; //Undefined behaviour
>
> Struct S { int getVal() { return 1; } }
> S s = void;
> s.getVal(); //Undefined behaviour
>
> Or do you mean:
>
> int n;
> n++;
>
> S s;
> s.getVal();

I mean uninitialised, ie, the former code (= void). Your later code is
default initialised.

On Tuesday, 11 June 2019 at 23:47:00 UTC, Manu wrote:
> On Tue, Jun 11, 2019 at 1:25 PM Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> Quick question, Manu. What are referring to when you say "uninitialized data"? Do you mean:
>>
>> int n = void;
>> n++; //Undefined behaviour
>>
>> Struct S { int getVal() { return 1; } }
>> S s = void;
>> s.getVal(); //Undefined behaviour
>>
>> Or do you mean:
>>
>> int n;
>> n++;
>>
>> S s;
>> s.getVal();
>
> I mean uninitialised, ie, the former code (= void). Your later code is
> default initialised.

In that case, yes, I'm in 110% agreement with you. Default-uninitialized variables are a well-known source of security vulnerabilities, and I thought that D *already* disallowed them in @safe code. This is a no-brainer.

On Tuesday, 11 June 2019 at 00:34:57 UTC, Manu wrote:
> On Mon, Jun 10, 2019 at 3:35 PM Max Haughton via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Monday, 10 June 2019 at 21:59:51 UTC, Ola Fosheim Grøstad wrote:
>> > On Monday, 10 June 2019 at 21:15:52 UTC, Walter Bright wrote:
>> >> On 6/10/2019 7:42 AM, Andrei Alexandrescu wrote:
>> >>> [...]
>> >>
>> >> Some reasons:
>> >>
>> >> https://stackoverflow.com/questions/4353203/thou-shalt-not-inherit-from-stdvector
>> >
>> > The answers with high rating actually state that there is no problem in inheriting from std::vector…
>> >
>> >> https://stackoverflow.com/questions/2034916/is-it-okay-to-inherit-implementation-from-stl-containers-rather-than-delegate
>> >
>> > The most highly rated answer says that there is no problem with inheriting from std::vector if you don't rely on on having a virtual destructor…
>> >
>> > So, not the best source for building an argument.
>>
>> Just because the code is semantically correct or "safe" doesn't mean it's good code. Inheriting from a container that you either aren't directly extending or don't own is a huge code smell in my view
>
> DRY. Base sets of members for consistency and minimising maintenance
> between collections of things are unbelievably common.
> DRY exists separately from polymorphism.

I'm not against struct inheritance per se, I just don't agree with using it without careful thought. I was more thinking along the lines of inheriting from std::vector in c++  when it would clearly be better to have one as a member. For your use of it, I think it should exist in the language.

On 11.06.19 13:03, Walter Bright wrote:
> 
> Here is what memory safety means:
> 
> "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers."
> 
>    -- https://en.wikipedia.org/wiki/Memory_safety
> 
> D defines @safe as "memory safe". It does not define it as "no undefined behavior".
> ...

Memory safety very much implies there can't be undefined behavior. Undefined behavior means the program can do anything, including overflowing buffers or freeing memory without destroying all references pointing to it. You may want to define it differently, but there is really no point. It will just confuse everyone who is familiar with another programming language that uses the standard meaning of the term.

> D does fall short of that goal, because it doesn't thoroughly track allocated memory pointers. But that has nothing to do with undefined values for integers.

Undefined values are not undefined behavior.


However, there are potential problems, based on which properties you want to assume that strongly pure functions have:

int foo()@safe pure{
    int x=void;
    return x;
}

Any code that is optimized based on the assumption that `foo()` will always return the same value will have undefined behavior, including the possibility of buffer overflows or dangling pointers.

On 6/12/2019 5:18 PM, Timon Gehr wrote:
> Undefined values are not undefined behavior.

I think that is the salient point. You're right.


> However, there are potential problems, based on which properties you want to assume that strongly pure functions have:
> 
> int foo()@safe pure{
>      int x=void;
>      return x;
> }
> 
> Any code that is optimized based on the assumption that `foo()` will always return the same value will have undefined behavior, including the possibility of buffer overflows or dangling pointers.

Optimizing it means caching the returned value. I don't see how that can lead to undefined behavior.