On Tuesday, 12 July 2016 at 01:28:31 UTC, Walter Bright wrote:
> I don't see anything actionable in your comment.

Defining by which way @safe actually ensure safety would be a good start.

I'm sorry for the frustration, but the "mention a problem, get asked for an example, provide example, example is debated to death while problem is ignored" cycle have become the typical interraction pattern around here and that is VERY frustrating.

On 07/11/2016 01:50 PM, deadalnix wrote:
> On Friday, 8 July 2016 at 19:26:59 UTC, Andrei Alexandrescu wrote:
>> On 07/08/2016 02:42 PM, deadalnix wrote:
>>> It is meaningless because sometime, you have A and B that are both safe
>>> on their own, but doing both is unsafe. In which case A or B need to be
>>> banned, but nothing allows to know which one. This isn't a bug, this is
>>> a failure to have a principled approach to safety.
>>
>> What would be a good example? Is there a bug report for it?
>>
>
> For instance:
>
> @safe
> int foo(int *iPtr) {
>      return *iPtr;
> }
>
> @safe
> int bar(int[] iSlice) {
>      return foo(iSlice.ptr);
> }

Here bar should not pass the @safe test because it may produce a non-dereferenceable pointer. Consider:

@safe int[] baz(int[] a) { return bar(a[$ .. $]; }

It is legal (and safe) to take an empty slice at the end of an array. Following the call, bar serves foo an invalid pointer that shan't be dereferenced.

I added https://issues.dlang.org/show_bug.cgi?id=16266. It looks to me like a corner case rather than an illustration of a systemic issue.

> foo assume that creating an invalid pointer is not safe, while bar
> assume that .ptr is safe as it doesn't access memory. If the slice's
> size is 0, that is not safe.
>
> This is one such case where each of this operation is safe granted some
> preconditions, but violate each other's preconditions so using both is
> unsafe.
>
>>> The position is inconsistent because the dictatorship refuses to
>>> compromise on mutually exclusive goals. For instance, @safe is defined
>>> as ensuring memory safety. But not against undefined behaviors (in fact
>>> Walter promote the use of UB in various situations, for instance when it
>>> comes to shared). You CANNOT have undefined behavior that are defined as
>>> being memory safe.
>>
>> I agree with that. What would be a good example? Where is the
>> reference to Walter's promotion of UB in @safe code?
>>
>
> I don't have a specific reference to point to right now.

"Don't do the crime if you can't do the time."


Andrei

On Monday, 11 July 2016 at 22:09:11 UTC, Walter Bright wrote:
> at one or more of the factors, Scheme included. Not Prolog either, a singularly useless, obscure and failed language.

Err... Prolog is in use and has been far more influential on the state of art than C++ or D ever will.

I think this discussion is dead...

On 7/11/2016 7:23 PM, deadalnix wrote:
> On Tuesday, 12 July 2016 at 01:28:31 UTC, Walter Bright wrote:
>> I don't see anything actionable in your comment.
>
> Defining by which way @safe actually ensure safety would be a good start.
>
> I'm sorry for the frustration, but the "mention a problem, get asked for
> an example, provide example, example is debated to death while problem
> is ignored" cycle have become the typical interraction pattern around
> here and that is VERY frustrating.
>

The example you gave of .ptr resulting in unsafe code has been in bugzilla since 2013, and has an open PR on it to fix it.

  https://issues.dlang.org/show_bug.cgi?id=11176

You didn't submit it to bugzilla - if you don't post problems to bugzilla, most likely they will get overlooked, and you will get frustrated. @safe issues are tagged with the 'safe' keyword in bugzilla. If you know of other bugs with @safe, and they aren't in the list, please add them. Saying generically that @safe has holes in it is useless information since it is not actionable and nobody keeps track of bugs posted on the n.g. nor are they even findable if you suspect they're there.

----

If I may rant a bit, lots of posters here posit that with "more process", everything will go better. Meanwhile, we DO have process for bug reports. They go to bugzilla. Posting bugs to the n.g. does not work. More process doesn't work if people are unwilling to adhere to it.

On 7/11/2016 7:46 PM, Ola Fosheim Grøstad wrote:
> On Monday, 11 July 2016 at 22:09:11 UTC, Walter Bright wrote:
>> at one or more of the factors, Scheme included. Not Prolog either, a
>> singularly useless, obscure and failed language.
>
> Err... Prolog is in use and has been far more influential on the state
> of art

"Prolog and other logic programming languages have not had a significant impact on the computer industry in general."

  https://en.wikipedia.org/wiki/Prolog#Limitations

So, no.


> than C++ or D ever will.

I'm afraid that is seriously mistaken about C++'s influence on the state of the art, in particular compile time polymorphism and the work of Igor Stepanov, and D's subsequent influence on C++.

Also, although C++ did not invent OOP, OOP's late 1980s surge in use, popularity, and yes, *influence* was due entirely to C++. I was there, in the center of that storm. Other languages fell all over themselves to add OOP extensions due to this. Java, Pascal, C#, etc. owe their OOP abilities to C++'s influence. Even Fortran got on the bandwagon.

On Tuesday, 12 July 2016 at 04:52:14 UTC, Walter Bright wrote:
> "Prolog and other logic programming languages have not had a significant impact on the computer industry in general."
>
>   https://en.wikipedia.org/wiki/Prolog#Limitations
>
> So, no.

That appears to be a 1995 reference from a logic programming languages conference. Of course logic programming has had a big impact on state of the art.

Prolog -> Datalog
Datalog -> magic sets
magic sets -> inference engines
inference engines  -> static analysis

And that is only a small part of it.

> I'm afraid that is seriously mistaken about C++'s influence on the state of the art, in particular compile time polymorphism

Nah. You are confusing state-of-the-art with widespread system support.

> Also, although C++ did not invent OOP, OOP's late 1980s surge in use, popularity, and yes, *influence* was due entirely to

In commercial application development sure. In terms of OOP principles and implementation, hell no.

On 08/07/16 22:26, Andrei Alexandrescu wrote:

> I agree with that. What would be a good example? Where is the reference
> to Walter's promotion of UB in @safe code?
>
>
> Andrei

I don't have an example by Walter, but I can give you an example by Andrei.

In D-Conf.

On Stage.

During the keynotes.

Immediately after knocking down C++ for doing the precise same thing, but in a that is both defined and less likely to produce errors.


The topic was reference counting's interaction with immutable (see deadalnix's comment, to which I completely agree, about inter-features interactions). When asked (by me) how you intend to actually solve this, you said that since you know where the memory comes from, you will cast away the immutability.

Casting away immutability is UB in D.

Not long before that, you laughed at C++ for it's "mutable" keyword, which allows doing this very thing in a way that is:
A. Fully defined (if you know what you're doing)
and
B. Not requiring a cast


C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support it.

D says any such cast is UB.

Shachar

On Tuesday, 12 July 2016 at 04:37:06 UTC, Walter Bright wrote:
> If I may rant a bit, lots of posters here posit that with "more process", everything will go better.

Gah, I hate this idea. It's pervasive in every office in the country. "Oh if we just had better tools we could manage our projects better." Meanwhile the manager on the project hasn't checked in with the engineers in week and probably has no idea what they're working on.

It's a people problem 99% of the time.

On 7/11/2016 10:01 PM, Ola Fosheim Grøstad wrote:
> Of course logic programming has had a big impact on state of
> the art.
>
> Prolog -> Datalog
> Datalog -> magic sets
> magic sets -> inference engines
> inference engines  -> static analysis
>
> And that is only a small part of it.

Can you trace any Prolog innovations in C/C++/Java/C#/Go/Rust/D/Swift/Javascript/Fortran/Lisp?

On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
> On 08/07/16 22:26, Andrei Alexandrescu wrote:
>
>> I agree with that. What would be a good example? Where is the reference
>> to Walter's promotion of UB in @safe code?
>>
>>
>> Andrei
>
> I don't have an example by Walter, but I can give you an example by Andrei.
>
> In D-Conf.
>
> On Stage.
>
> During the keynotes.
>
> Immediately after knocking down C++ for doing the precise same thing,
> but in a that is both defined and less likely to produce errors.

Love the drama. I was quite excited to see what follows :o).

> The topic was reference counting's interaction with immutable (see
> deadalnix's comment, to which I completely agree, about inter-features
> interactions).

Amaury failed to produce an example to support his point, aside from a rehash of a bug report from 2013 that is virtually fixed. Do you have any?

> When asked (by me) how you intend to actually solve this,
> you said that since you know where the memory comes from, you will cast
> away the immutability.
>
> Casting away immutability is UB in D.

I understand. There is an essential detail that sadly puts an anticlimactic end to the telenovela. The unsafe cast happens at allocator level. Inside any memory allocator, there is a point at which behavior outside the type system happens: memory that is untyped becomes typed, and vice versa (during deallocation). As long as you ultimately use system primitives from getting untyped bytes, at some point you'll operate outside the type system. It stands to reason, then, that at allocator level information and manipulations outside the type system's capabilities are possible and level so long as such manipulations are part of the standard library and offer defined behavior. This is par for the course in C++ and any systems language.

The solution (very ingenious, due to dicebot) in fact does not quite cast immutability away. Starting from a possibly immutable pointer, it subtracts an offset from it. At that point the memory is not tracked by the type system, but known to the allocator to contain metadata associated with the pointer that had been allocated with it. After the subtraction, the cast exposes the data which is mutable without violating the immutability of the object proper. As I said, it's quite an ingenious solution.

> Not long before that, you laughed at C++ for it's "mutable" keyword,
> which allows doing this very thing in a way that is:
> A. Fully defined (if you know what you're doing)
> and
> B. Not requiring a cast

I think we're in good shape with what we have; mutable has too much freedom and it's good to get away without it.



Andrei