www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP1000: Walter's proposal to resolve ambiguity of ref-return-scope

reply Dennis <dkorpel gmail.com> writes:
5 months ago I described an issue with `ref return scope` 
parameters:
[DIP1000: 'return scope' ambiguity and why you can't make opIndex 
work](https://forum.dlang.org/post/nbbtdbgifaurxoknyeuu forum.dlang.org)
(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`](https://github.com/atilaneves/automem/blob/8f61747f437b7624ad4b44085e9525fc143a9e6c/source/au
omem/vector.d#L209) or [return a `ref` as a
slice](https://github.com/dlang/druntime/blob/dded4c2b561784f71de88be433d6e2186ec7eeee/src/core/inter
al/convert.d#L804)? 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](https://issues.dlang.org/show_bug.cgi?id=22541)

What do you think of this proposal?
Nov 24 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:


 bugzilla issue:
 [Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope 
 parameters](https://issues.dlang.org/show_bug.cgi?id=22541)



[chinese 
version](https://fqbqrr.blog.csdn.net/article/details/121515578)
Nov 24 2021
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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](https://issues.dlang.org/show_bug.cgi?id=22541)

 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.
Nov 24 2021
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Nov 24 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
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?
Nov 25 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 25 2021
parent Dukc <ajieskola gmail.com> writes:
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.
Nov 25 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
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?
Nov 24 2021
parent reply zjh <fqbqrr 163.com> writes:
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`?
Nov 25 2021
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 25 November 2021 at 08:31:42 UTC, zjh wrote:

 What does `scope` mean?


`scope` on a variable with a pointer type means the pointer value 
will not leave the scope that the variable is declared in.


 Why I don't  understand it?


There are many special cases and the documentation isn't very 
good.


 What's the `point`?


To prevent memory corruption in ` safe` code when working with 
stack variables.
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 13:43:10 UTC, Dennis wrote:


 `scope` on a variable with a pointer type means the pointer 
 value will not leave the scope that the variable is declared in.


Thank you for your detailed explanation. I understand roughly.
If attribute deduction is available, can the `attr` be omitted as 
much as possible?
If we can't omit an attribute, I want `sugar sytax` to simplify 
it.
Looking at funcs, attrs all around, as a lover of clean code, I 
can't bear it.
Nov 25 2021
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 25 November 2021 at 14:16:21 UTC, zjh wrote:

 If attribute deduction is available, can the `attr` be omitted 
 as much as possible?


Yes


 Looking at funcs, attrs all around, as a lover of clean code, I 
 can't bear it.


You don't have to use the attributes, it's there for ` nogc` 
` safe` library code doing low-level memory management. Your 
applications are free to ignore it most of the time.

Also, 'clean code' is subjective. The alternative to `scope` 
parameters that you sometimes see in C libraries is a 'pointer 
lifetime' section in a documentation comment, which is:

- inconsistent (varies per library)
- not verified for correctness (compiler doesn't understand it)
- more verbose than a single `scope` keyword

I don't consider that clean.
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 14:40:09 UTC, Dennis wrote:


 I don't consider that clean.


I usually use `C++`,`C++` has no similar `scope`,`C++` has `RAII`.
It's like the `&` of `C++` versus the `ref` of `d`. `&` is much 
simpler than `ref`.
It would be nice if `d` had some `symbols/sugar syntax` to 
simplify these attributes.
Nov 25 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 25 November 2021 at 15:05:55 UTC, zjh wrote:

 On Thursday, 25 November 2021 at 14:40:09 UTC, Dennis wrote:


 I don't consider that clean.


 I usually use `C++`,`C++` has no similar `scope`,`C++` has 
 `RAII`.
 It's like the `&` of `C++` versus the `ref` of `d`. `&` is much 
 simpler than `ref`.
 It would be nice if `d` had some `symbols/sugar syntax` to 
 simplify these attributes.


I wonder what the reason was to choose ref instead of &. Maybe 
it's kinder to the parser.
Nov 25 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 25 November 2021 at 15:27:20 UTC, Imperatorn wrote:

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

 On Thursday, 25 November 2021 at 14:40:09 UTC, Dennis wrote:


 I don't consider that clean.


 I usually use `C++`,`C++` has no similar `scope`,`C++` has 
 `RAII`.
 It's like the `&` of `C++` versus the `ref` of `d`. `&` is 
 much simpler than `ref`.
 It would be nice if `d` had some `symbols/sugar syntax` to 
 simplify these attributes.


 I wonder what the reason was to choose ref instead of &. Maybe 
 it's kinder to the parser.


If you are new to D and don't already know C++, `int&` will mean 
nothing to you, whereas you have at least a chance of guessing 
what `ref int` means just from reading it.
Nov 25 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 25 November 2021 at 15:59:41 UTC, Paul Backus wrote:

 On Thursday, 25 November 2021 at 15:27:20 UTC, Imperatorn wrote:

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

 On Thursday, 25 November 2021 at 14:40:09 UTC, Dennis wrote:


 I don't consider that clean.


 I usually use `C++`,`C++` has no similar `scope`,`C++` has 
 `RAII`.
 It's like the `&` of `C++` versus the `ref` of `d`. `&` is 
 much simpler than `ref`.
 It would be nice if `d` had some `symbols/sugar syntax` to 
 simplify these attributes.


 I wonder what the reason was to choose ref instead of &. Maybe 
 it's kinder to the parser.


 If you are new to D and don't already know C++, `int&` will 
 mean nothing to you, whereas you have at least a chance of 
 guessing what `ref int` means just from reading it.


So it was more of a readability thing then
Nov 25 2021
parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 25 November 2021 at 16:05:01 UTC, Imperatorn wrote:

 On Thursday, 25 November 2021 at 15:59:41 UTC, Paul Backus 
 wrote:

 If you are new to D and don't already know C++, `int&` will 
 mean nothing to you, whereas you have at least a chance of 
 guessing what `ref int` means just from reading it.


 So it was more of a readability thing then


I'm only guessing, but I suspect it's a combination of (a) 
readability, and (b) consistency with other storage classes 
(which are all words, not punctuation).
Nov 25 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 15:59:41 UTC, Paul Backus wrote:


 If you are new to D and don't already know C++, `int&` will 
 mean nothing to you, whereas you have at least a chance of 
 guessing what `ref int` means just from reading it.


`ref` is a very simple concept. It is similar to `alias`. It is 
easy for beginners to understand, `alias and nickname`, who 
doesn't understand?
Obviously `&` is much simpler than `ref`, and even more funny, 
some people doubt `||` and `&&` and want to replace it with 
`and/or`.
Clearly see the symbols, you understand it.
but I don't understand, Why should I use words?
Like `py`, full of `self/and/or`, it looks like an ugly design. 
Does anyone like it?
Nov 25 2021
parent zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 01:05:39 UTC, zjh wrote:


 Like `py`, full of `self/and/or`, it looks like an ugly design.


Of course, there are more funny ones, such as `rust`'s `::`, 
obviously `C++`'s `::`, which is ugly. These people don't even 
feel it. `rust` is a full screen of `symbols`, as well as kinds 
of ugly `abbreviations`, plus kinds of disgusting redundant 
functions, and `<<<>>>` etc, which is very funny.
`some language` is kinds of ugliness.


Rust cannot copied everything right, which is very funny.
Nov 25 2021
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
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.
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 16:22:32 UTC, Dennis wrote:


 used symbols such as `^%` and `^$` (for example), that wouldn't 
 make it simpler.


I've been saying, offer options, rather than the only 
one.`(||/&&)` or `and|or` is provided.
Both `simplified symbols and complete words` are provided for 
users to choose.
Of course, it's best to complete the attribute deduction by 
compiler, and the user doesn't have to write it at all.
Nov 25 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 01:28:25 UTC, zjh wrote:


 and the user doesn't have to write it at all.


Here users include `library authors`.
Nov 25 2021
prev sibling parent Greg Strong <mageofmaple protonmail.com> writes:
On Friday, 26 November 2021 at 01:28:25 UTC, zjh wrote:

 I've been saying, offer options, rather than the only 
 one.`(||/&&)` or `and|or` is provided.
 Both `simplified symbols and complete words` are provided for 
 users to choose.
 Of course, it's best to complete the attribute deduction by 
 compiler, and the user doesn't have to write it at all.


I disagree with everything you just wrote.

1.  Adding more redundant options does not make the situation 
better.

2.  The point of the attribute declarations ( safe for example) 
is to tell the compiler what you want it to be so that it can 
stop and give you an error if you are wrong.  Having it deduce 
 safe only if it is actually safe accomplishes nothing.
Nov 25 2021
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Work in progress:

https://github.com/dlang/dmd/pull/13357
Nov 25 2021
prev sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

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

 [...]


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.
Nov 25 2021
parent reply Dennis <dkorpel gmail.com> writes:
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:

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

     }
}
```
Nov 25 2021
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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:

 ```D
 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:

```d
struct S {
     ref int opIndex(return ref scope this) {
         // ...
     }
}
```
Nov 25 2021
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 25 November 2021 at 19:35:53 UTC, Paul Backus 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:

 ```D
 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:

 ```d
 struct S {
     ref int opIndex(return ref scope this) {
         // ...
     }
 }
 ```


I really like this suggestion! It's a lot cleaner than having all 
the attributes after the function (which sometimes means the same 
as before the function)

Would be a lot easier to understand to people who have never seen 
attributes after the function before. (Like people coming from 


However it would be inconsistent to keep the other attributes 
after the function as well and I doubt anyone would prefer

```d
int width(const  property this) { ... }
                 // doesn't really make sense imo, would need to 
at least keep the   attributes (and pure, nothrow) after the 
function
```

over

```d
int width() const  property { ... }
```

What is nice that stuff like const/inout would make more sense 
(writing it before the function meaning the same as after the 
function unless there are parentheses would be no more)

Would think you could write it like this:

```d
inout int[] getSomething(inout return this, int offset)  property 
{ ... }
```
Nov 25 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 November 2021 at 07:44:22 UTC, WebFreak001 wrote:

 Would think you could write it like this:

 ```d
 inout int[] getSomething(inout return this, int offset) 
  property { ... }
 ```


Yes, this is what I had in mind. You'd write the attributes 
exactly the same way you would for a non-member function.
Nov 26 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 14:48:21 UTC, Paul Backus wrote:


 ```d
 inout int[] getSomething(inout return this, int offset) 
  property { ... }
 ```




Why copy `rust`.

Classes are inherently for `encapsulation`.

here is too ugly. I can use `C++` concept to implement it.

It's so simple, you don't even have to declare `this`.

`Rust` is synonymous with ugliness. Let's not copy it.
Nov 26 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 27 November 2021 at 01:17:15 UTC, zjh wrote:

 On Friday, 26 November 2021 at 14:48:21 UTC, Paul Backus wrote:


 ```d
 inout int[] getSomething(inout return this, int offset) 
  property { ... }
 ```




 Why copy `rust`.


Actually, I got the idea from Python. :)

Why do I think it's a good idea? Because it makes it really 
obvious which attributes apply to `this` and which attributes 
apply to the function as a whole.

For example, here's a really common error that beginning D 
programmers make:

```d
struct S
{
     private int[] a;
     const int[] getArray() const { return a; }
}
```

If you try to compile this code, you get the following error:

```
Error: redundant attribute `const`
```

The reason for this is that in the above code, *both* instances 
of `const` are treated as applying to the `this` reference, not 
to the return value. The fix is to add `()` to the first `const`:

```d
     const(int[]) getArray() const { return a; }
```

With an explicit `this` parameter, there is no room for ambiguity:

```d
     const int[] getArray(const ref this) { return a; }
```

The outer `const` can only apply to the return value, and the 
inner `const` can only apply to the `this` reference.
Nov 26 2021
next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Saturday, 27 November 2021 at 03:41:05 UTC, Paul Backus wrote:

 On Saturday, 27 November 2021 at 01:17:15 UTC, zjh wrote:

 [...]


 Actually, I got the idea from Python. :)

 Why do I think it's a good idea? Because it makes it really 
 obvious which attributes apply to `this` and which attributes 
 apply to the function as a whole.

 [...]


I have been mumbling to myself about this for a while. I think 
it's a fundamentally better way of expressing the attribute soup.

Can we actually switch? Not sure...
Nov 26 2021
parent Paul Backus <snarwin gmail.com> writes:
On Saturday, 27 November 2021 at 04:20:57 UTC, max haughton wrote:

 On Saturday, 27 November 2021 at 03:41:05 UTC, Paul Backus 
 wrote:

 On Saturday, 27 November 2021 at 01:17:15 UTC, zjh wrote:

 [...]


 Actually, I got the idea from Python. :)

 Why do I think it's a good idea? Because it makes it really 
 obvious which attributes apply to `this` and which attributes 
 apply to the function as a whole.

 [...]


 I have been mumbling to myself about this for a while. I think 
 it's a fundamentally better way of expressing the attribute 
 soup.

 Can we actually switch? Not sure...


I don't know about "switch", but we can certainly add the new 
syntax as an optional alternative to the current version. Most 
likely the original syntax will never entirely go away, though, 
just like the original `alias old new;` syntax, so the real 
question is whether having both is better than just having the 
current version.
Nov 26 2021
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 27, 2021 at 03:41:05AM +0000, Paul Backus via Digitalmars-d wrote:
[...]

 For example, here's a really common error that beginning D programmers
 make:
 
 ```d
 struct S
 {
     private int[] a;
     const int[] getArray() const { return a; }
 }
 ```
 
 If you try to compile this code, you get the following error:
 
 ```
 Error: redundant attribute `const`
 ```
 
 The reason for this is that in the above code, *both* instances of
 `const` are treated as applying to the `this` reference, not to the
 return value.  The fix is to add `()` to the first `const`:


[...]

IMO, const as a type qualifier should *always* be used with parentheses.
Things like `const int` are a code smell, and an invitation to trouble
like the above.  This is D, not C, so we should be writing things the D
way, i.e., `const(int)` instead of `const int` like we do in C/C++.

Another case is the subtle but important difference between `const(X)[]`
and `const(X[])`.  When you write `const X[]` it's not immediately
obvious which one you get.  This is also a cause of stumbling for D
beginners.

Therefore, IMNSHO it's a misfeature that the D compiler accepts `const
int`. It should reject such cases and always require parentheses, then
there would be no ambiguity.  Had parentheses been mandatory from the
beginning, people would have learned to write const(X)[] and const(X[])
unambiguously, and this would not have been a problem at all. Optional
parentheses is a source of needless trouble.

Ditto with immutable, inout, and any other type constructor.


T

-- 
A mathematician learns more and more about less and less, until he knows
everything about nothing; whereas a philospher learns less and less
about more and more, until he knows nothing about everything.
Nov 26 2021
parent zjh <fqbqrr 163.com> writes:
On Saturday, 27 November 2021 at 04:31:31 UTC, H. S. Teoh wrote:


 write const(X)[] and const(X[]) unambiguously, and this would 
 not have been a problem at all. Optional parentheses is a 
 source of needless trouble.

 Ditto with immutable, inout, and any other type constructor.



Your post has many good ideas and should be collected.
Nov 26 2021
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 27 November 2021 at 03:41:05 UTC, Paul Backus wrote:


 ```d
 struct S
 {
     private int[] a;
     const int[] getArray() const { return a; }
 }
 ```


We should collect a beginner's `error prone` items,And put a link 
on the home page.
can we like this?
```d
 constthis
const int[] getArray() { return a; }
```
`python`'s `self` is everywhere,it's very annoying.
Nov 26 2021
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Saturday, 27 November 2021 at 03:41:05 UTC, Paul Backus wrote:

 For example, here's a really common error that beginning D 
 programmers make:

 ```d
 struct S
 {
     private int[] a;
     const int[] getArray() const { return a; }
 }
 ```


...

 With an explicit `this` parameter, there is no room for 
 ambiguity:

 ```d
     const int[] getArray(const ref this) { return a; }
 ```

 The outer `const` can only apply to the return value, and the 
 inner `const` can only apply to the `this` reference.


Explicit `this` parameter is OK but more verbose. It also could 
be confusing for learners if declaring the `this` parameter is 
not required for methods with no `this` attributes. And if it is 
required, would that break existing code? I suppose there could 
be a rule that all methods of a type must follow the same 
convention.

Another solution is to require attributes that apply to `this` to 
go after the parameters, not before. That would be less verbose, 
but may break code and so would need a long deprecation cycle. 
(This was first suggested some years ago).
Nov 27 2021
prev sibling next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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:

 ```D
 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

```d
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.
Nov 25 2021
next sibling parent reply Dennis <dkorpel gmail.com> writes:
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?
Nov 25 2021
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 22:36:38 UTC, Walter Bright 
wrote:


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


`lazy` can be deleted completely. One can replace it with 
something similar to the `concept` of C++.
` safe  nogc pure nothrow auto ref fuck(ref int x) return ref 
scope;`.
What can be deleted from this thing?
May be we only need to keep `auto`, and at most keep the ` safe` 
series, and all the rest are deducted.
It's better to delete it all. It's too ugly.
nothrow, pure,  nogc,... should all be the default.
Provide the user with a script to update the default.
Nov 25 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 November 2021 at 01:48:28 UTC, zjh wrote:

 On Thursday, 25 November 2021 at 22:36:38 UTC, Walter Bright 
 wrote:


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


 `lazy` can be deleted completely. One can replace it with 
 something similar to the `concept` of C++.


There's one use of `lazy` that can't be easily replaced, which is 
template functions like [`std.exception.ifThrown`][1]. Without 
`lazy`, we would have to rewrite code like this

```d
auto result = doStuff(x, y, z).ifThrown(w);
```

...to look like this:

```d
auto result = (() => doStuff(x, y, z)).ifThrown(w);
```

Personally I don't think this is a huge deal--`lazy` is not very 
commonly used in the first place, and having to write a few extra 
characters in the places where it is used is not a terrible 
imposition. But it is still a breaking change.

[1]: https://phobos.dpldocs.info/std.exception.ifThrown.1.html
Nov 25 2021
parent zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 02:08:54 UTC, Paul Backus wrote:


 ```d
 auto result = doStuff(x, y, z).ifThrown(w);
 ```

 ...to look like this:

 ```d
 auto result = (() => doStuff(x, y, z)).ifThrown(w);
 ```


single λ, It's really hard to change.
But if more than one `λ`, You can use the concept like. It's very 
convenient.
We should not encourage the use of `lazy`, keep it, but not 
encourage it.
Nov 25 2021
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
Nov 25 2021
parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:

 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.


Allowing breaking changes, what syntax do you think makes 
intuitive sense?
Nov 25 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 November 2021 at 00:31:19 UTC, Dennis wrote:

 On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:

 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.


 Allowing breaking changes, what syntax do you think makes 
 intuitive sense?


* Allow `return ref` and `return scope`.
* Forbid the `return` storage class from appearing in any other 
context.

This means breaking code that uses syntax like `ref return int a` 
and `return const ref int b`, which is unambiguous and currently 
allowed.

The benefit of this approach is that it establishes an exact, 
one-to-one correspondence between syntax and semantics. Rather 
than having to apply a bunch of context-dependent rules to work 
out which attributes go where, you can just look at the code and 
see.
Nov 25 2021
parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Friday, 26 November 2021 at 02:03:41 UTC, Paul Backus wrote:

 On Friday, 26 November 2021 at 00:31:19 UTC, Dennis wrote:

 On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:

 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.


 Allowing breaking changes, what syntax do you think makes 
 intuitive sense?


 * Allow `return ref` and `return scope`.
 * Forbid the `return` storage class from appearing in any other 
 context.


As an occasional D(hobby) user but long-time lurker on this 
forum... it has been noticeable t me that D is gradually 
approaching C++ in complexity!

Something like this, as you hinted,...


 ```d
 struct S {
     ref int opIndex(return ref scope this) {
         // ...
     }
 }
 ```


... are inevitably going to be confusing to newbies.

Personally what I think would help is to somehow 'link' those 
keywords together that is a single entity i.e. in your example 
`return ref` and `return scope` becomes `return-ref` and 
`return-scope`.

Or anything similar that achieves the same, like `return_ref` and 
`return_scope`, as long as it is clear that they are not separate 
keywords in this context. Or whatever makes the most sense from a 
lexing/parsing POV.

It will at least read easier and be easier to explain (like `ref 
int opIndex(return-ref scope this)` is allowed, but not `ref int 
opIndex(ref-return scope this)`, compared to `ref int 
opIndex(return ref scope this)` is allowed, but not `ref int 
opIndex(ref return scope this)` .

I realize this in effect introduces new keywords and is equally a 
breaking change, but in my opinion this is preferable to the 
explosion in parameter attributes we are seeing.
Nov 26 2021
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 26 November 2021 at 10:32:54 UTC, ShadoLight wrote:

 On Friday, 26 November 2021 at 02:03:41 UTC, Paul Backus wrote:

 * Allow `return ref` and `return scope`.
 * Forbid the `return` storage class from appearing in any 
 other context.


 As an occasional D(hobby) user but long-time lurker on this 
 forum... it has been noticeable t me that D is gradually 
 approaching C++ in complexity!

 Something like this, as you hinted,...


 ```d
 struct S {
     ref int opIndex(return ref scope this) {
         // ...
     }
 }
 ```


 ... are inevitably going to be confusing to newbies.

 Personally what I think would help is to somehow 'link' those 
 keywords together that is a single entity i.e. in your example 
 `return ref` and `return scope` becomes `return-ref` and 
 `return-scope`.


Yes, I also think this would be ideal. Someone in a previous 
thread proposed the syntax `return(ref)` and `return(scope)`, 
which would make this possible without introducing new keywords.

However, given the stance Walter and the rest of the core team 
have towards breaking changes, I don't think it's likely they'd 
accept a proposal like this, which makes no concession at all to 
existing usage.
Nov 26 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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:

 ```D
 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

 ```d
 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 😁
```d
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
```
Nov 25 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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 😁
 ```d
 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
```d
 safe  nogc pure nothrow auto ref fuck(ref int x) return ref 
scope;
```
Nov 25 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 21:08:37 UTC, Imperatorn wrote:


 Don't forget 😁
 ```d
 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
 ```



Our `inout` first used to solved this problem.
Now, We should use it to solve this problem again.
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 02:00:38 UTC, zjh wrote:

I think,`&` can replace `ref` at all.
`&`,No better than `ref`?
why we don't use `&`?
Nov 25 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 02:05:00 UTC, zjh wrote:


 why we don't use `&`?


```d
auto ref f3(ref int x) { return x; }
//VS
auto&f3(int&x){return x;}
```
one `inout` is enough:
```d
auto inout f3(inout int&x) inout{return x;}
//VS
auto what() return;
auto the() return scope;
auto fuck() return ref scope;
...
```
Nov 25 2021
parent zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 02:17:18 UTC, zjh wrote:

`Return ref` replace with ` `,and `return scope` replace with `%`
Why not?
```d
struct S {
     ref int opIndex() return ref scope {
     }
}
//VS
struct S {
     int&opIndex() %{

     }
}
```
Nov 25 2021
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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).
Nov 25 2021
prev sibling parent forkit <forkit gmail.com> writes:
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'.
Nov 25 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 25 November 2021 at 16:11:39 UTC, Dennis wrote:

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

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

     }
 }
 ```


Perhaps it still makes sense to allow free `return` qualifier 
with member functions? The invisible `this` parameter is 
implicitly `ref`, so that repeating `ref` just for the `return` 
qualifier wouldn't be needed.

We might still require the `return` for the invisible `ref this` 
to be the last qualifier, so no `ref int opIndex() return const 
scope` or anything like that.
Nov 26 2021
parent reply Araq <rumpf_a web.de> writes:
& vs ref is just one of the many things that C++ does better than 
D. And I'm not talking about the syntax: What is a "storage 
class"? And assuming this terms means anything, why would "ref" 
be one? In what world is a hidden pointer a "storage class"?
Nov 26 2021
next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 & vs ref is just one of the many things that C++ does better 
 than D. And I'm not talking about the syntax: What is a 
 "storage class"? And assuming this terms means anything, why 
 would "ref" be one? In what world is a hidden pointer a 
 "storage class"?


C++ has storage classes too. `auto` and `static`, perhaps others 
I can't immediately recall. D adds `ref`, `__gshared`, `enum` and 
`lazy` on top of those. `const`, `shared` and `immutable` can be 
syntactically used as storage classes, but in reality they just 
alias to `auto` or `__ghared` and add a type qualifier at the 
same time.
Nov 26 2021
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 What is a "storage class"?


A property of a variable declaration that says something about 
the memory it is stored in. In C, that could be e.g. `register` 
or `volatile`. In D, that could be `__gshared`, which says a 
global variable is stored in the data section instead of thread 
local storage (default).


 And assuming this terms means anything, why would "ref" be one?


It's a property of a parameter (which is a variable declaration) 
that says it's not stored in this function's frame, but somewhere 
higher up.


 In what world is a hidden pointer a "storage class"?


You don't explicitly spell out the `this` parameter in member 
functions, but `ref` is not 'hidden'.

You are right though that making `ref` a storage class is a 
questionable decision, it adds a lot of complexity to the 
compiler, which has tons of split code paths (a search for 
`isref` gives me 229 hits). Same for `scope`, which is also 
questionable as a storage class: it doesn't even say anything 
about the variable itself, only about the variable that the 
pointer points to.
Nov 26 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 & vs ref is just one of the many things that C++ does better 
 than D. And I'm not talking about the syntax: What is a 
 "storage class"? And assuming this terms means anything, why 
 would "ref" be one? In what world is a hidden pointer a 
 "storage class"?


If you don't know about C++ or D you can always ask in the learn 
forums.
Nov 26 2021
parent Araq <rumpf_a web.de> writes:
On Friday, 26 November 2021 at 15:31:53 UTC, Imperatorn wrote:

 On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 & vs ref is just one of the many things that C++ does better 
 than D. And I'm not talking about the syntax: What is a 
 "storage class"? And assuming this terms means anything, why 
 would "ref" be one? In what world is a hidden pointer a 
 "storage class"?


 If you don't know about C++ or D you can always ask in the 
 learn forums.


Ha, good one.
Nov 26 2021
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 & vs ref is just one of the many things that C++ does better 
 than D. And I'm not talking about the syntax


See this post for why C++ `&` is more complicated and harder to 
understand than D `ref`:
https://forum.dlang.org/post/rlssnqdidtsqjwxpmudb forum.dlang.org
Nov 26 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 26 November 2021 at 15:42:13 UTC, Nick Treleaven wrote:


 See this post for why C++ `&` is more complicated and harder to 
 understand than D `ref`:
 https://forum.dlang.org/post/rlssnqdidtsqjwxpmudb forum.dlang.org


`C++` references, which look complicated, are actually simple.

And D `ref`, no matter what, I hate it.
A '&' is `Ok`,why not `use` it?
There are too many 'attributes', can we delete? I'm writing 
functions, not `attrs`.
Nov 26 2021
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 27 November 2021 at 01:10:37 UTC, zjh wrote:

 `C++` references, which look complicated, are actually simple.


Try reading the C++ spec, you will see the rules are far more 
complicated than D `ref`.


 And D `ref`, no matter what, I hate it.


Not helpful without giving a reason.


 A '&' is `Ok`,why not `use` it?


Because:
1. `ref` is not part of the type, so it is used less often and we 
don't need a sigil for it. It should stand out, it's important.
2. `&` is already an operator, it's best not to overload sigils.
3. C++ `&` (as a type constructor) is different from D `ref` 
semantically, so we should not use the same syntax to avoid 
introducing bugs when porting code from C++.


 There are too many 'attributes', can we delete? I'm writing 
 functions, not `attrs`.


If we are to support checked memory safety we need more 
attributes than C++, which doesn't support it. In general 
attributes could be inferred when the function body is there, but 
I think that is only implemented for templates ATM. Perhaps it 
would impact compile-times.
Nov 27 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 27 November 2021 at 11:10:42 UTC, Nick Treleaven 
wrote:


 it would impact compile-times.


`compile-times` is faster than `manual write`.
Nov 27 2021
parent reply russhy <russhy gmail.com> writes:
consistency!


we have ``int*`` for pointers

let's use ``int&`` for references


consistency > everything else, i don't use ref because i hate 
typing it, same for immutable
Nov 27 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 27 November 2021 at 14:35:17 UTC, russhy wrote:

 consistency!
 we have ``int*`` for pointers
 let's use ``int&`` for references
 consistency > everything else, i don't use ref because i hate 
 typing it, same for immutable


D's main selling point is elegance.
Sometimes, I think `C++` is more elegant than `d`. It's totally 
incredible.
We need to slash something and simplify something.
No programmer don't want to be lazy. No one wants to type 
more.the same for the `libwriter`.
Nov 27 2021
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Saturday, 27 November 2021 at 14:35:17 UTC, russhy wrote:

 consistency > everything else


Storage classes in D consistently use keywords, making it look 
similar to int* (which is a type, not a storage class) would be 
inconsistent.


 i don't use ref because i hate typing it, same for immutable


That sounds more like conciseness, not consistency.
Nov 27 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2021 6:35 AM, russhy wrote:

 consistency!
 
 
 we have ``int*`` for pointers
 
 let's use ``int&`` for references
 
 
 consistency > everything else, i don't use ref because i hate typing it, same 
 for immutable


There's almost nothing consistent about the way & is in C++.
Nov 27 2021
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2021 3:10 AM, Nick Treleaven wrote:

 If we are to support checked memory safety we need more attributes than C++, 
 which doesn't support it. In general attributes could be inferred when the 
 function body is there, but I think that is only implemented for templates
ATM. 
 Perhaps it would impact compile-times.


Any case where the source to the function is required, such as template 
functions and `auto` return functions, gets their attributes inferred.

The reason is for consistent behavior if just the function declaration is 
visible, rather than the function definition (i.e. body). The decision is done 
by the canInferAttributes() function.
Nov 27 2021
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2021 3:10 AM, Nick Treleaven wrote:

 On Saturday, 27 November 2021 at 01:10:37 UTC, zjh wrote:

 `C++` references, which look complicated, are actually simple.


 
 Try reading the C++ spec, you will see the rules are far more complicated than
D 
 `ref`.


C++'s & for ref is part of the type system, but it is such a special type that 
it messes with every aspect of the type system.

This comes about because & can only appear at the "head" of a type (a "pointer 
to ref to int" cannot be declared), and there are many, many rules saying when 
the ref type is significant and when it is skipped.

D made the better decision to have `ref` be orthogonal to the type.
Nov 27 2021
parent russhy <russhy gmail.com> writes:
On Saturday, 27 November 2021 at 18:27:43 UTC, Walter Bright 
wrote:

 On 11/27/2021 3:10 AM, Nick Treleaven wrote:

 On Saturday, 27 November 2021 at 01:10:37 UTC, zjh wrote:

 `C++` references, which look complicated, are actually simple.


 
 Try reading the C++ spec, you will see the rules are far more 
 complicated than D `ref`.


 C++'s & for ref is part of the type system, but it is such a 
 special type that it messes with every aspect of the type 
 system.

 This comes about because & can only appear at the "head" of a 
 type (a "pointer to ref to int" cannot be declared), and there 
 are many, many rules saying when the ref type is significant 
 and when it is skipped.

 D made the better decision to have `ref` be orthogonal to the 
 type.


i can see understand that point

i personally stick to pointers only in my codebase, because i 
like simplicity, i didn't even use & back when i was using C++, 
it always felt dirty anyways
Nov 27 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

 & vs ref is just one of the many things that C++ does better 
 than D. And I'm not talking about the syntax: What is a 
 "storage class"? And assuming this terms means anything, why 
 would "ref" be one? In what world is a hidden pointer a 
 "storage class"?


"&" is used for many different things in C++, that is not good. 
Also, having two different reference types is confusing to 
newbies and creates trouble for generic programming.

D should try hard (and harder) to be simpler than C++, yet remain 
familiar to C++ programmers and equally predictable, that is the 
path to adoption.

If D can keep return-scope etc out of application code, then it 
is ok.

(Although D might need annotations that are more specific and 
expressive for libraries, but that is a different topic.)
Nov 26 2021