On 10/07/16 02:44, H. S. Teoh via Digitalmars-d wrote:
> I find this rather disturbing, actually.  There is a fine line between
> taking advantage of assert's to elide stuff that the programmer promises
> will not happen, and eliding something that's defined to be UB and
> thereby resulting in memory corruption.

I like clang's resolution to this problem. On the one hand, leaving things undefined allows the compiler to optimize away cases that would, otherwise, be horrible for performance.

On the other hand, these optimizations sometimes turn code that was meant to be okay into really not okay.

LLVM, at least for C and C++, has an undefined behavior sanitizer. You can turn it on, and any case where a test that superficial reading of the code suggests takes place, but was optimized away due to undefined behavior, turns into a warning. This allows you to write code in a sane way while not putting in a ton (metric or otherwise, as I won't fight over 10% difference) of security holes.

Shachar

On 7/11/2016 10:15 PM, Shachar Shemesh wrote:
> D says any such cast is UB.

That's why such casts are not allowed in @safe code. There's also no way to write a storage allocator in @safe code.

Code that is not checkably safe is needed in real world programming. The difference between D and C++ here is that D provides a means of marking such code as unsafe so the rest can be checkably safe, and C++ does not.

On Tuesday, 12 July 2016 at 05:30:57 UTC, Walter Bright wrote:
> 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?

I think you are taking the wrong view here. Logic programming is a generalized version of functional programming where you can have complex expressions in the left hand side. It is basically unification:

https://en.wikipedia.org/wiki/Unification_(computer_science)#Application:_Unification_in_logic_programming

So yes, many languages are drawing on those principles in their type systems.

On 7/11/2016 10:42 PM, Ola Fosheim Grøstad wrote:
> So yes, many languages are drawing on those principles in their type
> systems.

D draws many features that come from functional programming. But I am not aware of any that come specifically from Prolog.

And just to be clear, D aims to be a useful programming language. It is not intended as a vehicle for programming language research.

It is also entirely possible for a research language to advance the state of the art (i.e. programming language theory), but not be useful. That is not what D is about, though.

D's job is to get s*** done quickly and effiently and make money for the businesses that use it.

On 2016-07-12 06:37, Walter Bright wrote:

> 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.

Not sure if this is what deadalnix thinks about but @safe should be a whitelist of features, not a blacklist [1]. But you already closed that bug report as invalid.

[1] https://issues.dlang.org/show_bug.cgi?id=12941

-- 
/Jacob Carlborg

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. 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.

If you think I'm advocating for more process, you've been mislead. More process doesn't work, in general. Even if people are willing to adhere to it.

If you think the issue I have is with one specific bug, same thing.

On Tuesday, 12 July 2016 at 05:33:00 UTC, Andrei Alexandrescu wrote:
> 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?
>

Finger moon. I presented maybe 5 exemple of what I'm talking about already and it is still not enough. You guys keep wanting to discuss every single example to death to avoid doing the hard thinking.

> 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.
>

True but once again, finger, moon, etc...

On Tuesday, 12 July 2016 at 06:36:18 UTC, Jacob Carlborg wrote:
> Not sure if this is what deadalnix thinks about but @safe should be a whitelist of features, not a blacklist [1]. But you already closed that bug report as invalid.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=12941

I think that we should have a set of rule that we can look at and that provide an insurance that things are memory safe. Whitelist vs blacklist is an implementation detail (while surely, whitelist seems like a better approach).

On 12/07/16 08:33, Andrei Alexandrescu wrote:
> On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
>> 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?


UFCS: Anywhere you can do "func(a)" you can also do "a.func()" and vice versa.

Operator ->: Not needed, as we know this is a pointer to a struct. We automatically dereference with the dot operator.

struct A {
    void method() {}
}

void main() {
    A* a;

    a.method(); // Okay
    method(a);  // Not okay
}



>
>> 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).

Nah, this is cut and dried. You should just continue being nicely turbed. "Casting away immutability has undefined behavior" is what it is. [1]

It is quite okay, and even unavoidable, to go outside the type system inside an allocator. It something else entirely to invoke UB.

The C++ definition is quite solid. Casting away constness is UB IFF the buffer was originally const.

In this case, your allocator does two UBs. One when allocating (casting a mutable byte range to immutable reference), and another when deallocating. Both are defined as undefined by D, which means the compiler is free to wreak havoc in both without you having the right to complain.

Which leads me to the conclusion that you cannot write an allocator in D. I doubt that's a conclusion you'd stand behind.

Shachar

1 - https://forum.dlang.org/post/nlsbtr$2vaq$1@digitalmars.com

On Tuesday, 12 July 2016 at 06:29:36 UTC, Walter Bright wrote:
> And just to be clear, D aims to be a useful programming language. It is not intended as a vehicle for programming language research.

Neither was Prolog.  It is used for useful programming as well as education (e.g. teaching unification to students).  It isn't suited for programming-in-the-large, but that doesn't make it useless. And to be frank D's symbol resolution isn't suitable for programming-in-the-large either.

Of course, Prolog is old and there are also other alternatives for various types of problem solving, but the fact that almost every CS student have some understanding of Prolog unification makes it very influential.