On Tuesday, 12 July 2016 at 05:37:54 UTC, Walter Bright wrote:
> 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.

Code that *could* cause undefined behaviour given certain inputs is unsafe code. Can be ok if you're careful.

Code that *does* do undefined behaviour isn't just unsafe, it's undefined. Never OK.


If casting away immutability is undefined behaviour in D, then all paths of execution* that do it are undefined.

For the previous statement to be false, you must define cases where casting away immutability *is* defined.

On 7/12/2016 12:20 AM, deadalnix wrote:
> If you think the issue I have is with one specific bug, same thing.

There aren't any open issues with 'safe' that have been reported by you. Of the open issues, I don't think any of them show anything fundamentally broken about @safe.

If you've got other specific issues in mind, please file them.

On 7/12/2016 2:40 AM, John Colvin wrote:
> For the previous statement to be false, you must define cases where
> casting away immutability *is* defined.

@system programming is, by definition, operating outside of the language guarantees of what happens. It's up to you, the systems programmer, to know what you're doing there.

On 7/12/2016 12:23 AM, deadalnix wrote:
> I presented maybe 5 exemple of what I'm talking about already

Links, please. There are perhaps 300,000 messages in this n.g.

On 7/12/2016 12:35 AM, Shachar Shemesh wrote:
> 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
> }

I'm afraid I don't know what you're driving at with those examples.

On Tuesday, 12 July 2016 at 09:40:09 UTC, John Colvin wrote:
> On Tuesday, 12 July 2016 at 05:37:54 UTC, Walter Bright wrote:
>> 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.
>
> Code that *could* cause undefined behaviour given certain inputs is unsafe code. Can be ok if you're careful.
>
> Code that *does* do undefined behaviour isn't just unsafe, it's undefined. Never OK.
>
>
> If casting away immutability is undefined behaviour in D, then all paths of execution* that do it are undefined.
>
> For the previous statement to be false, you must define cases where casting away immutability *is* defined.

Strongly agree.

With `synchronize` we already have a problematic case of casting away immutability (dmdfe internally) where an optimizing compiler generates bad code. Let's not add more.

On 7/12/2016 1:41 AM, Ola Fosheim Grøstad wrote:
> And to be frank D's symbol resolution isn't suitable for programming-in-the-large
> either.

Explain.


> teaching

Frictionless masses are useful for teaching engineering, but are not useful in the real world, which tends to be complicated and dirty, just like useful programming languages.


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

I asked for one feature originating in Prolog that made its way into mainstream languages.

You dismissed C++'s enormous influence in getting languages to adopt OOP, but defend Prolog influencing others with unification.

On Tuesday, 12 July 2016 at 00:34:12 UTC, sarn wrote:
>
> Scheme is a really nice, elegant language that's fun to hack with, but at the end of the day, if people were writing Nginx, or the Windows kernel, or HFT systems in Scheme, you can bet programmers would be pushing pretty hard for special exceptions and hooks and stuff for better performance or lower-level access, and eventually you'd end up with another C.
>

Honestly after writing a toy Scheme interpreter, I've come to think much more highly of Javascript.

On 12/07/16 13:25, Walter Bright wrote:
> On 7/12/2016 12:35 AM, Shachar Shemesh wrote:
>> 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
>> }
>
> I'm afraid I don't know what you're driving at with those examples.
>

It is a single example. It shows that when UCFS and the lack of operator -> try to play together, the result is no longer as simple and elegant as one tries to sell them. It was given as a response to Andrei's request for examples of cross-features interference causing complexity.

Shachar

On 7/12/2016 3:31 AM, Johan Engelen wrote:
> With `synchronize` we already have a problematic case of casting away
> immutability (dmdfe internally) where an optimizing compiler generates
> bad code. Let's not add more.

Is there a bugzilla issue for this?