Jump to page: 1 28  
Page
Thread overview
DIP1000: Walter's proposal to resolve ambiguity of ref-return-scope parameters
5 days ago
Dennis
5 days ago
zjh
5 days ago
Paul Backus
4 days ago
Walter Bright
4 days ago
Dukc
4 days ago
Walter Bright
4 days ago
Dukc
4 days ago
zjh
4 days ago
zjh
4 days ago
Dennis
4 days ago
zjh
4 days ago
Dennis
4 days ago
zjh
4 days ago
Imperatorn
4 days ago
Paul Backus
4 days ago
Imperatorn
4 days ago
Paul Backus
4 days ago
zjh
4 days ago
zjh
4 days ago
Dennis
4 days ago
zjh
4 days ago
zjh
4 days ago
Greg Strong
4 days ago
Walter Bright
4 days ago
WebFreak001
4 days ago
Dennis
4 days ago
Paul Backus
3 days ago
WebFreak001
3 days ago
Paul Backus
3 days ago
zjh
3 days ago
Paul Backus
3 days ago
max haughton
3 days ago
Paul Backus
3 days ago
H. S. Teoh
2 days ago
zjh
2 days ago
zjh
2 days ago
Nick Treleaven
4 days ago
Dennis
4 days ago
Walter Bright
4 days ago
zjh
4 days ago
Paul Backus
4 days ago
zjh
4 days ago
Paul Backus
4 days ago
Dennis
4 days ago
Paul Backus
3 days ago
ShadoLight
3 days ago
Paul Backus
4 days ago
Imperatorn
4 days ago
Imperatorn
4 days ago
zjh
4 days ago
zjh
4 days ago
zjh
4 days ago
zjh
4 days ago
forkit
3 days ago
Dukc
3 days ago
Araq
3 days ago
Dukc
3 days ago
Dennis
3 days ago
Imperatorn
3 days ago
Araq
3 days ago
Nick Treleaven
3 days ago
zjh
2 days ago
Nick Treleaven
2 days ago
zjh
2 days ago
russhy
2 days ago
zjh
2 days ago
Dennis
2 days ago
Walter Bright
2 days ago
Walter Bright
2 days ago
Walter Bright
2 days ago
russhy
5 days ago

5 months ago I described an issue with ref return scope parameters:
DIP1000: 'return scope' ambiguity and why you can't make opIndex work
(N.b. in struct member functions, the this keyword is a ref parameter)

The gist of it is that the return keyword both appears in return ref and return scope, but currently the parser doesn't look at the ordering of the ref return scope keywords, so the decision is made by this rule:

  • If the function returns by ref, it favors return ref, otherwise it favors return scope.

What if you want to return a slice element by ref or return a ref as a slice? Tough luck.

But wait, that rule is only what the specification says should happen. dmd actually has its own ways of choosing between return ref and return scope:

>

Consider the following types:

P contains indirections
I does not contain indirections
X may or may not contain indirections

Currently, the ambiguity is resolved:

a. P foo(ref return scope P p) => ref returnScope

b. I foo(ref return scope P p) => returnRef scope (!!)

c. ref X foo(ref return scope P p) => returnRef scope

d. X foo(ref return scope I) => returnRef (!!)

e. ref X foo(ref return scope I) => returnRef

Walter describes this existing behavior, as well as a proposed solution to explicitly allow the missing cases, in this bugzilla issue:
Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope parameters

What do you think of this proposal?

5 days ago

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

>

bugzilla issue:
Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope parameters

chinese version

5 days ago

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

>

Walter describes this existing behavior, as well as a proposed solution to explicitly allow the missing cases, in this bugzilla issue:
Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope parameters

What do you think of this proposal?

Not a fan. It's a special case, and it's completely invisible to anyone who hasn't read the language spec cover-to-cover.

IMO we should only do this if we also apply it to return ref, and deprecate the return attribute in any position other than immediately before ref or scope—i.e., we essentially make return ref and return scope into "compound keywords".

Another thing I'd like to see addressed by this (or any) proposal is how it interacts with attribute inference. Do these new combinations only work when the attributes are explicitly given, rather than inferred? If so, that will mean that they cannot be used in many cases for generic code—e.g., if my template function may call a user-defined copy constructor of some generic type T, I cannot manually mark that parameter as return scope, since I do not know in advance whether the copy constructor conforms to those attributes.

4 days ago

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

The whole code is full of Unnecessary attributes(ref return scope). It's annoying to look at it. Can't it be as simple as C++?
D needs major changes. Don't tangle. There are so few users now, When will we big change without taking advantage of it?

4 days ago
On 11/24/2021 9:02 PM, Paul Backus wrote:
> IMO we should only do this if we also apply it to `return ref`,

The proposal already does that.

> and deprecate the `return` attribute in any position other than immediately before `ref` or `scope`—i.e., we essentially make `return ref` and `return scope` into "compound keywords".

That's the longer term goal. But meanwhile, I don't want to break too much existing code.

> Another thing I'd like to see addressed by this (or any) proposal is how it interacts with attribute inference. Do these new combinations *only* work when the attributes are explicitly given, rather than inferred?

They'll be inferred. Otherwise, attribute inference is useless.

> If so, that will mean that they cannot be used in many cases for generic code—e.g., if my template function may call a user-defined copy constructor of some generic type `T`, I cannot manually mark that parameter as `return scope`, since I do not know in advance whether the copy constructor conforms to those attributes.

I.e. useless :-)

4 days ago

On Thursday, 25 November 2021 at 05:02:44 UTC, Paul Backus wrote:

>

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

>

What do you think of this proposal?

>

IMO we should only do this if we also apply it to return ref, and deprecate the return attribute in any position other than immediately before ref or scope—i.e., we essentially make return ref and return scope into "compound keywords".

That is a good idea IMO. Might require a deprecation period for return !(ref / scope) though.

This raises a question: will return ref return scope become allowed?

4 days ago
Work in progress:

https://github.com/dlang/dmd/pull/13357
4 days ago
On 11/25/2021 12:12 AM, Dukc wrote:
> This raises a question: will `return ref return scope` become allowed?

No.

Consider the following code:

  void* func(T** p, bool b)
  {
     if (b)
	return p;
     else
        return *p;
  }

I propose that such code has quite a smell emanating from it, and so don't see a good reason to support `return ref return scope` as that will endorse such code.

4 days ago

On Thursday, 25 November 2021 at 06:29:36 UTC, zjh wrote:

What does scope mean? Why I don't understand it? What's the point?

4 days ago

On Thursday, 25 November 2021 at 08:20:32 UTC, Walter Bright wrote:

>

On 11/25/2021 12:12 AM, Dukc wrote:

>

This raises a question: will return ref return scope become allowed?

No.

Consider the following code:

void* func(T** p, bool b)
{
if (b)
return p;
else
return *p;
}

I propose that such code has quite a smell emanating from it, and so don't see a good reason to support return ref return scope as that will endorse such code.

Lol, I obviously wasn't thinking much what the qualifier set would mean. Good point, that would be a bit like having string roundToInteger(float) in Phobos.

« First   ‹ Prev
1 2 3 4 5 6 7 8