November 25, 2021

On Thursday, 25 November 2021 at 15:05:55 UTC, zjh wrote:

>

I usually use C++,C++ has no similar scope,C++ has RAII.

The idea of scope is allowing @safe access to raw pointers/arrays with limited lifetime. RAII in C++ doesn't do anything to protect basic types like that.

>

It would be nice if d had some symbols/sugar syntax to simplify these attributes.

What are you thinking of? If return scope and return ref used symbols such as ^% and ^$ (for example), that wouldn't make it simpler.

November 25, 2021

On Thursday, 25 November 2021 at 16:11:39 UTC, Dennis wrote:

>

On Thursday, 25 November 2021 at 15:57:13 UTC, WebFreak001 wrote:

>

with return ref and return scope, will there also be a return this for the case like the opIndex functions returning something with the lifetime of the containing struct? I don't quite get how it's otherwise fixing it.

return this in struct member functions is return ref. Walter proposes in the bugzilla issue to allow ref after the parameter list:

struct S {
    ref int opIndex() return ref scope {

    }
}

Seems like we may be reaching the point where it's worth it to make the this parameter explicit, like it is in Python and Rust:

struct S {
    ref int opIndex(return ref scope this) {
        // ...
    }
}
November 25, 2021

On Thursday, 25 November 2021 at 16:11:39 UTC, Dennis wrote:

>

On Thursday, 25 November 2021 at 15:57:13 UTC, WebFreak001 wrote:

>

with return ref and return scope, will there also be a return this for the case like the opIndex functions returning something with the lifetime of the containing struct? I don't quite get how it's otherwise fixing it.

return this in struct member functions is return ref. Walter proposes in the bugzilla issue to allow ref after the parameter list:

struct S {
    ref int opIndex() return ref scope {

    }
}

Jesus... Recall how, at that one DConf, Scott Meyers suggested that D would be wise to not require a Scott Meyers? Well what do you know, if you have

ref what() return;
ref the() return scope;
ref fuck() return ref scope;

all in the same language, then you'd need a Meyers-Sutter hybrids mass-cloned 24/7 in a specialized facility for the sole purpose of teaching this stuff, if you want the language to get anywhere. And some enslaved clones of Andrei locked away in a basement, churning out book after book titled "Writing code that don't not work". Something stinks something fierce here.

https://dlang.org/spec/function.html#parameters needs to get simpler, not turn into a PhD thesis, which it is already well on the way to.

November 25, 2021

On Thursday, 25 November 2021 at 20:45:41 UTC, Stanislav Blinov wrote:

>

https://dlang.org/spec/function.html#parameters needs to get simpler, not turn into a PhD thesis, which it is already well on the way to.

My proposal (as mentioned in the issue) is that return in any other position than directly before scope refers to return-ref, so only return scope results in return-scope. Also I think lazy and out can go, though suggesting to remove a feature tends to bring out people who like the feature and oppose the removal.

What do you propose?

November 25, 2021

On Thursday, 25 November 2021 at 20:45:41 UTC, Stanislav Blinov wrote:

>

On Thursday, 25 November 2021 at 16:11:39 UTC, Dennis wrote:

>

On Thursday, 25 November 2021 at 15:57:13 UTC, WebFreak001 wrote:

>

with return ref and return scope, will there also be a return this for the case like the opIndex functions returning something with the lifetime of the containing struct? I don't quite get how it's otherwise fixing it.

return this in struct member functions is return ref. Walter proposes in the bugzilla issue to allow ref after the parameter list:

struct S {
    ref int opIndex() return ref scope {

    }
}

Jesus... Recall how, at that one DConf, Scott Meyers suggested that D would be wise to not require a Scott Meyers? Well what do you know, if you have

ref what() return;
ref the() return scope;
ref fuck() return ref scope;

all in the same language, then you'd need a Meyers-Sutter hybrids mass-cloned 24/7 in a specialized facility for the sole purpose of teaching this stuff, if you want the language to get anywhere. And some enslaved clones of Andrei locked away in a basement, churning out book after book titled "Writing code that don't not work". Something stinks something fierce here.

https://dlang.org/spec/function.html#parameters needs to get simpler, not turn into a PhD thesis, which it is already well on the way to.

Don't forget 😁

ref what() return;
ref the() return scope;
ref fuck() return ref scope;

auto ref what() return;
auto ref the() return scope;
auto ref fuck() return ref scope;

auto ref f1(int x)     { return x; }  // value return
auto ref f2()          { return 3; }  // value return
auto ref f3(ref int x) { return x; }  // ref return
auto ref f4(out int x) { return x; }  // ref return
auto ref f5() { static int x; return x; }

// etc
November 25, 2021

On Thursday, 25 November 2021 at 21:08:37 UTC, Imperatorn wrote:

>

On Thursday, 25 November 2021 at 20:45:41 UTC, Stanislav Blinov wrote:

>

[...]

Don't forget 😁

ref what() return;
ref the() return scope;
ref fuck() return ref scope;

auto ref what() return;
auto ref the() return scope;
auto ref fuck() return ref scope;

auto ref f1(int x)     { return x; }  // value return
auto ref f2()          { return 3; }  // value return
auto ref f3(ref int x) { return x; }  // ref return
auto ref f4(out int x) { return x; }  // ref return
auto ref f5() { static int x; return x; }

// etc

Sorry I meant

@safe @nogc pure nothrow auto ref fuck(ref int x) return ref scope;
November 26, 2021
On 26/11/2021 9:45 AM, Stanislav Blinov wrote:
> https://dlang.org/spec/function.html#parameters needs to get __simpler__, not turn into a PhD thesis, which it is already well on the way to.

Provability is the future of programming language design.

However D should have had it from day one, since Walter did look at ML when designing D. Where a lot of this stuff originates from.

Now as far as D's attributes for proofing are concerned, unfortunately they have to stay in some form. Although I would much rather see new keywords which include two underscores in the front than reusing return ext.

They are required for extern's and function pointers where inference cannot happen (which needs to be the default because right now, it is far too cluttered to do right and adds far too much for a lot of people to think about).
November 25, 2021
On 11/25/2021 1:07 PM, Dennis wrote:
> My proposal (as mentioned in the issue) is that `return` in any other position than directly before `scope` refers to return-ref, so only `return scope` results in return-scope. Also I think `lazy` and `out` can go, though suggesting to remove a feature tends to bring out people who like the feature and oppose the removal.

I've suggested removing `lazy` already, with the predicted response.
November 26, 2021

On Thursday, 25 November 2021 at 20:45:41 UTC, Stanislav Blinov wrote:

>

https://dlang.org/spec/function.html#parameters needs to get simpler, not turn into a PhD thesis, which it is already well on the way to.

"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." - Alan Perlis, American Scientist .

We need more of these 'geniuses'.

November 26, 2021

On Thursday, 25 November 2021 at 21:07:50 UTC, Dennis wrote:

>

On Thursday, 25 November 2021 at 20:45:41 UTC, Stanislav Blinov wrote:

>

https://dlang.org/spec/function.html#parameters needs to get simpler, not turn into a PhD thesis, which it is already well on the way to.

My proposal (as mentioned in the issue) is that return in any other position than directly before scope refers to return-ref, so only return scope results in return-scope. [...]

What do you propose?

If I ever have to explain to someone in the Learn forum why scope return means something different from return scope, I will cry.

More seriously: this is exactly the kind of obscure "gotcha" that makes C++ so beginner-hostile, and IMO it is worth going to considerable lengths (including breaking changes) to avoid it.