www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - `ref T` should be a type!!

reply Victor Porton <porton narod.ru> writes:
That `ref T` (where T is a type) is not a type is a serious 
design error, because so `ref T` cannot be used as a template 
argument.

It is a very serious problem.

Even in C++ despite of all its silliness, T& is a type and can be 
used as a template argument.

Can the language be changed to resolve this problem?
Mar 29
next sibling parent reply Alex <sascha.orlov gmail.com> writes:
On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error, because so `ref T` cannot be used as a template 
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and can 
 be used as a template argument.

 Can the language be changed to resolve this problem?
Could you show an example, where an alias parameter is not enough?
Mar 29
next sibling parent Rubn <where is.this> writes:
On Friday, 29 March 2019 at 16:18:59 UTC, Alex wrote:
 On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error, because so `ref T` cannot be used as a template 
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and can 
 be used as a template argument.

 Can the language be changed to resolve this problem?
Could you show an example, where an alias parameter is not enough?
An alias and a type are two different things and have different use cases.
Mar 29
prev sibling parent reply Victor Porton <porton narod.ru> writes:
On Friday, 29 March 2019 at 16:18:59 UTC, Alex wrote:
 On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error, because so `ref T` cannot be used as a template 
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and can 
 be used as a template argument.

 Can the language be changed to resolve this problem?
Could you show an example, where an alias parameter is not enough?
The following does not work: class C(alias T) { } C(ref int) a;
Mar 29
parent bauss <jj_1337 live.dk> writes:
On Friday, 29 March 2019 at 20:49:20 UTC, Victor Porton wrote:
 On Friday, 29 March 2019 at 16:18:59 UTC, Alex wrote:
 On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error, because so `ref T` cannot be used as a template 
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and 
 can be used as a template argument.

 Can the language be changed to resolve this problem?
Could you show an example, where an alias parameter is not enough?
The following does not work: class C(alias T) { } C(ref int) a;
Why do you expect it to work? What exactly are you supposed to do with that? ref can only be used as parameters and thus it would only ever work like: class C(alias T) { void foo(T bar) { ... } } C!(ref int) baz; Which is just ugly and makes no sense. And also in that case alias is unnecessary. class C(T) { void foo(T bar) { ... } } C!(ref int) baz; Which still makes no sense. Is there a reason why you cannot do the following? class C(T) { void foo(ref T bar) { ... } } Because why would you ever want the implementation of a function to behave differently depending on whether its parameters are passed by reference or not. In fact instead there should be a ref overload and one without.
Mar 29
prev sibling next sibling parent reply Rubn <where is.this> writes:
On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error, because so `ref T` cannot be used as a template 
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and can 
 be used as a template argument.

 Can the language be changed to resolve this problem?
You can't have reference variables in D, and I doubt walter will allow them. It doesn't make much sense to have a type that allows ref if you can't declare a variable with it.
Mar 29
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2019 12:55 PM, Rubn wrote:
 You can't have reference variables in D, and I doubt walter will allow them.
It 
 doesn't make much sense to have a type that allows ref if you can't declare a 
 variable with it.
You can't declare a pointer to a ref in C++, either. It's not a real type.
Mar 31
parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 00:18:40 UTC, Walter Bright wrote:
 On 3/29/2019 12:55 PM, Rubn wrote:
 You can't have reference variables in D, and I doubt walter 
 will allow them. It doesn't make much sense to have a type 
 that allows ref if you can't declare a variable with it.
You can't declare a pointer to a ref in C++, either. It's not a real type.
It's a type with a restriction, you can literally use it everywhere else you can use a type. A reference is just a pointer with a dress on, having a naked pointer go with a dressed pointer doesn't make much sense. Taking the address of a reference returns a pointer to the object the reference points to, not a pointer to the reference. It's impossible to get the address of the actual reference (* without some hack). But sure it's not a type because you can't have a pointer to it. std::is_same_v<int, int&>;
Mar 31
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Mar 31
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Sun, Mar 31, 2019 at 6:20 PM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error
It could though with some innovative design, and that would be *awesome*.
 A C++ ref can only appear at the top of a type AST, which is unlike any other
 type. Which exactly matches the only place a storage class can be!
So, what you're saying is, C++ was able to implement storage class semantics, but without distinguishing storage class from the type, thereby making it accessible to any type construction or introspection machinery that the language has available? Apparently C++ was genius in this way; why would you invent storage class specifically to exclude ref from the ability to interact with type construction and introspection machinery? ref sucks because it can't interact with type construction or introspection. Every meta-interaction with ref is via kludgey hacks. You mention the complexity of ref in C++, but that needs to be balanced against the entire concept of 'storage class' in D, and literally every single rule relating to it, since that's the counter-weight. If you take the aggregate of all rules and semantics related to 'storage class' in D, especially when including consideration that we have lost the ability to do type construction or introspection in storage classes, is that REALLY simpler than C++?
Mar 31
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2019 6:30 PM, Manu wrote:
 A C++ ref can only appear at the top of a type AST, which is unlike any other
 type. Which exactly matches the only place a storage class can be!
So, what you're saying is, C++ was able to implement storage class semantics, but without distinguishing storage class from the type, thereby making it accessible to any type construction or introspection machinery that the language has available? Apparently C++ was genius in this way; why would you invent storage class specifically to exclude ref from the ability to interact with type construction and introspection machinery? ref sucks because it can't interact with type construction or introspection. Every meta-interaction with ref is via kludgey hacks.
Um, have you looked at the special, kludgey rules for refs that permeate the C++ spec? Just about every rule for types has a special case for refs. For example, C++ does type inference in various contexts. Sometimes the ref is inferred, sometimes it is skipped. Can you describe when it is inferred and when it isn't, and why?
 You mention the complexity of ref in C++, but that needs to be
 balanced against the entire concept of 'storage class' in D, and
 literally every single rule relating to it, since that's the
 counter-weight. If you take the aggregate of all rules and semantics
 related to 'storage class' in D, especially when including
 consideration that we have lost the ability to do type construction or
 introspection in storage classes, is that REALLY simpler than C++?
Yes. Keep in mind that I implemented ref in C++, every last gory detail. I've earned my opinion of it.
Apr 01
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Apr 1, 2019 at 3:40 AM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 3/31/2019 6:30 PM, Manu wrote:
 A C++ ref can only appear at the top of a type AST, which is unlike any other
 type. Which exactly matches the only place a storage class can be!
So, what you're saying is, C++ was able to implement storage class semantics, but without distinguishing storage class from the type, thereby making it accessible to any type construction or introspection machinery that the language has available? Apparently C++ was genius in this way; why would you invent storage class specifically to exclude ref from the ability to interact with type construction and introspection machinery? ref sucks because it can't interact with type construction or introspection. Every meta-interaction with ref is via kludgey hacks.
Um, have you looked at the special, kludgey rules for refs that permeate the C++ spec? Just about every rule for types has a special case for refs. For example, C++ does type inference in various contexts. Sometimes the ref is inferred, sometimes it is skipped. Can you describe when it is inferred and when it isn't, and why?
I understand the rules are complex. But I'm saying that 1; I don't believe we *must* implement the complexity exactly the same way if ref were part of the type. and 2; if you're being honest, you need to balance that complexity you describe against the complexity introduced by the _idea_ of storage class, every single detail relating to its implementation, and the loss of language to interact with type construction and introspection. Storage class and all related implementation and semantics are *hugely* complicated, and I think it's worse because it's a parallel system with an unrelated set of rules that you have to remember distinctly, and no language for meaningful interaction. You can't choose to ignore details about meta-interaction with storage class as part of that complexity, they are major. Whereas C++ ref rules are founded in type construction, which, while needing to understand some special cases, don't require understanding a whole parallel ecosystem. I find it hard to judge that the storage class solution can be considered simpler than the complexity that you refer to from C++, and I also think it's a false comparison, because I suspect we could paint the rules simpler than C++ if we tried. Storage class == text mixin, and the worst kinds of text mixins, because they usually affect the function signature. Because text mixins must form a complete expression, if you ever need to do text-mixin on a function signature, the **entire function** must be written as a string which is unreasonably hideous. Storage class is the worst thing in D. I love to make over-inflated claims, but I say this with absolute conviction. There is nothing about D more upsetting than storage class; it is functionally incompatible with introspection and generative meta, and that's D's strongest value proposition. How can you say a feature that's fundamentally incompatible with meta-programming is great?
 You mention the complexity of ref in C++, but that needs to be
 balanced against the entire concept of 'storage class' in D, and
 literally every single rule relating to it, since that's the
 counter-weight. If you take the aggregate of all rules and semantics
 related to 'storage class' in D, especially when including
 consideration that we have lost the ability to do type construction or
 introspection in storage classes, is that REALLY simpler than C++?
Yes. Keep in mind that I implemented ref in C++, every last gory detail. I've earned my opinion of it.
The goal is to make language painless and enjoyable for authors, not necessarily for compiler developers, that's just a nice bonus. I'm not saying it *must* be like C++ (I suspect a less-complex set of rules is possible), I'm just saying it's better. What it should NOT be, is a completely separate mechanism outside of the language like storage class. Perhaps you can invent another meta-language for interacting with storage-class... I've tried to imagine it, but I really struggle to picture something satisfying.
Apr 04
parent Daniel N <no public.email> writes:
On Thursday, 4 April 2019 at 07:21:34 UTC, Manu wrote:
 Perhaps you can invent another meta-language for interacting 
 with storage-class... I've tried to imagine it, but I really 
 struggle to picture something satisfying.
I wanted this a long time, declarations as template params. fun!(ref int x); Every part should be possible to introspect including storage class and variable name.
Apr 04
prev sibling parent reply Dein <dwin d.com> writes:
On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Apr 01
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 1 April 2019 at 13:09:28 UTC, Dein wrote:
 On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Bad example, but the point stands: ---- // foo.cpp int fun() { int& foo[5]; // doesn't compile } ---- I'd never even thought of it until Walter mentioned it that one can't have an array of references. Huh.
Apr 01
next sibling parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 13:57:17 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 13:09:28 UTC, Dein wrote:
 On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Bad example, but the point stands: ---- // foo.cpp int fun() { int& foo[5]; // doesn't compile } ---- I'd never even thought of it until Walter mentioned it that one can't have an array of references. Huh.
Arrays in C++ are just pointers. If you can't have a pointer to something, it is only natural you can't have array either. void* ptr; // ok void arr[5]; // error So I guess Walter agrees that void isn't a type then right? You can't have an array to it so that's the deciding factor.
Apr 01
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
 If you can't have a pointer to something, it is 
 only natural you can't have array either.
g++ -c test.cpp test.cpp: In function void test(): test.cpp:1:24: error: declaration of p as array of references void test() { int& p[3]; } ^ As I said, C++ ref can only appear at the top of an AST, which is what a "storage class" is. C++ tries to have it be both a floor wax and a desert topping, making for a device that nobody understands. Be careful what you wish for.
Apr 01
next sibling parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 20:51:44 UTC, Walter Bright wrote:
 On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
Yes they are. The only time an array exists in C++ is (oddly) only when you pass it by reference :). Otherwise every operation you do on array, any time you pass an array to a function that isn't a reference it is just a pointer. This is why buffer overflows exist in C++, because an is literally just a pointer -- it doesn't even know it's own size! How can you call that an array?
 If you can't have a pointer to something, it is only natural 
 you can't have array either.
g++ -c test.cpp test.cpp: In function void test(): test.cpp:1:24: error: declaration of p as array of references void test() { int& p[3]; } ^ As I said, C++ ref can only appear at the top of an AST, which is what a "storage class" is. C++ tries to have it be both a floor wax and a desert topping, making for a device that nobody understands.
So you are saying void is also a "storage class" ?
 Be careful what you wish for.
I'm not wishing for anything. You entered the discussion and stated that it isn't a type. And that's what I've been arguing against.
Apr 01
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 2 April 2019 at 00:00:34 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 20:51:44 UTC, Walter Bright wrote:
 On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
Yes they are. The only time an array exists in C++ is (oddly) only when you pass it by reference :). Otherwise every operation you do on array, any time you pass an array to a function that isn't a reference it is just a pointer. This is why buffer overflows exist in C++, because an is literally just a pointer -- it doesn't even know it's own size! How can you call that an array?
Every word in this paragraph is wrong, including "the", "yes", and "it".
Apr 01
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/01/2019 05:00 PM, Rubn wrote:
 On Monday, 1 April 2019 at 20:51:44 UTC, Walter Bright wrote:
 On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
Yes they are.
Sensational but wrong. For example, there is no pointer in the following C++ code yet there is an array: #include <iostream> using namespace std; struct S { int arr[10]; }; int main() { cout << sizeof(S) << '\n'; } I know that you can qualify your statement to make it correct in some contexts but you are not doing so (yet?). Ali
Apr 01
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 2 April 2019 at 00:00:34 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 20:51:44 UTC, Walter Bright wrote:
 On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
Yes they are. The only time an array exists in C++ is (oddly) only when you pass it by reference :). Otherwise every operation you do on array, any time you pass an array to a function that isn't a reference it is just a pointer. This is why buffer overflows exist in C++, because an is literally just a pointer -- it doesn't even know it's own size! How can you call that an array?
I love it, stridently arguing with Walter about the basics of C++, one of the few people in the world who groks the basics of the language well enough to implement a compiler for it*! Obviously there's always a chance he's wrong about things, but on a topic like this? Very bad odds. :) * Memorizing the standard & writing a million lines of C++ code would be no guarantee of getting to this level.
Apr 02
prev sibling parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 20:51:44 UTC, Walter Bright wrote:
 On 4/1/2019 1:00 PM, Rubn wrote:
 Arrays in C++ are just pointers.
No, they're not.
 If you can't have a pointer to something, it is only natural 
 you can't have array either.
g++ -c test.cpp test.cpp: In function void test(): test.cpp:1:24: error: declaration of p as array of references void test() { int& p[3]; } ^ As I said, C++ ref can only appear at the top of an AST, which is what a "storage class" is. C++ tries to have it be both a floor wax and a desert topping, making for a device that nobody understands. Be careful what you wish for.
Let's put it this way, is const a type? No? You would say it is a "sturage class". Considering the following now though: What do you think the following code is going to print? import std.stdio; void foo(T)(T a) { writeln(T.stringof); } template is_same(T, G) { enum is_same = is(T == G); } void main() { int a; const int b; foo( a ); foo( b ); writeln( "is_same: ", is_same!(typeof(a), typeof(b)) ); }
Apr 01
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2019 5:20 PM, Rubn wrote:
 Let's put it this way, is const a type?
No. It's a "type qualifier".
Apr 02
parent reply Rubn <where is.this> writes:
On Tuesday, 2 April 2019 at 07:58:21 UTC, Walter Bright wrote:
 On 4/1/2019 5:20 PM, Rubn wrote:
 Let's put it this way, is const a type?
No. It's a "type qualifier".
Enough so that it is called a storage class in the DMD source code.
Apr 03
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03.04.19 21:56, Rubn wrote:
 On Tuesday, 2 April 2019 at 07:58:21 UTC, Walter Bright wrote:
 On 4/1/2019 5:20 PM, Rubn wrote:
 Let's put it this way, is const a type?
No. It's a "type qualifier".
Enough so that it is called a storage class>
Syntactically, it is both. However, annotating a variable with `const` will apply the type qualifier to its type without affecting how it is stored.
 in the DMD source code.
Check out mtype.d.
Apr 03
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03.04.19 22:36, Timon Gehr wrote:
 On 03.04.19 21:56, Rubn wrote:
 On Tuesday, 2 April 2019 at 07:58:21 UTC, Walter Bright wrote:
 On 4/1/2019 5:20 PM, Rubn wrote:
 Let's put it this way, is const a type?
No. It's a "type qualifier".
Enough so that it is called a storage class>
Syntactically, it is both. However, annotating a variable with `const` will apply the type qualifier to its type without
_necessarily_
 affecting how it is stored.
(But it can, e.g. static const variables will be put into the readonly data section.)
Apr 03
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 1 April 2019 at 20:00:34 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 13:57:17 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 13:09:28 UTC, Dein wrote:
 On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Bad example, but the point stands: ---- // foo.cpp int fun() { int& foo[5]; // doesn't compile } ---- I'd never even thought of it until Walter mentioned it that one can't have an array of references. Huh.
Arrays in C++ are just pointers. If you can't have a pointer to something, it is only natural you can't have array either.
Arrays in C (and by extension C++) are most definitely not "just pointers". This is a common misconception due to arrays decaying to pointers in function calls. There are such things as array pointers in C, and C++ adds array references to the mix for, in all likelihood, consistency. I haven't met many C programmers that know of their existence.
     void* ptr;   // ok
     void arr[5]; // error

 So I guess Walter agrees that void isn't a type then right? You 
 can't have an array to it so that's the deciding factor.
Funnily enough your example here shows how pointers and arrays aren't the same thing. The reason you can't have an array of "voids" in C is because void has no size and the whole thing is nonsensical. It's a good point though that void is treated differently in C's type system.
Apr 01
next sibling parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 23:04:15 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 20:00:34 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 13:57:17 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 13:09:28 UTC, Dein wrote:
 On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a 
 type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Bad example, but the point stands: ---- // foo.cpp int fun() { int& foo[5]; // doesn't compile } ---- I'd never even thought of it until Walter mentioned it that one can't have an array of references. Huh.
Arrays in C++ are just pointers. If you can't have a pointer to something, it is only natural you can't have array either.
Arrays in C (and by extension C++) are most definitely not "just pointers". This is a common misconception due to arrays decaying to pointers in function calls. There are such things as array pointers in C, and C++ adds array references to the mix for, in all likelihood, consistency. I haven't met many C programmers that know of their existence.
     void* ptr;   // ok
     void arr[5]; // error

 So I guess Walter agrees that void isn't a type then right? 
 You can't have an array to it so that's the deciding factor.
Funnily enough your example here shows how pointers and arrays aren't the same thing. The reason you can't have an array of "voids" in C is because void has no size and the whole thing is nonsensical. It's a good point though that void is treated differently in C's type system.
I never said they are the same thing. An array can only (with a minor exception) be represented by a pointer, if a pointer can't exist then neither can the array.
Apr 01
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 2 April 2019 at 00:06:23 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 23:04:15 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 20:00:34 UTC, Rubn wrote:
 On Monday, 1 April 2019 at 13:57:17 UTC, Atila Neves wrote:
 On Monday, 1 April 2019 at 13:09:28 UTC,
 Funnily enough your example here shows how pointers and arrays 
 aren't the same thing. The reason you can't have an array of 
 "voids" in C is because void has no size and the whole thing 
 is nonsensical. It's a good point though that void is treated 
 differently in C's type system.
I never said they are the same thing.
"Arrays in C++ are just pointers".
 An array can only (with a minor exception) be represented by a 
 pointer, if a pointer can't exist then neither can the array.
Factually incorrect.
Apr 01
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection. I wrote an article about it calling this "C's Biggest Mistake", as this has led to decades of crashes and malware infestations: https://www.digitalmars.com/articles/b44.html
Apr 02
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/2/19 4:11 AM, Walter Bright wrote:
 On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection.
You forgot to mention that top-level "const" is ignored in function parameters (for the signature and mangling but not the implementation). Now the fact that "42" is just ignored in the declaration below is indistinguishable from conspiracy: void fun(int a[42]);
Apr 02
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2019 4:05 AM, Andrei Alexandrescu wrote:
 You forgot to mention that top-level "const" is ignored in function parameters 
 (for the signature and mangling but not the implementation).
Curiously, it is present in the name mangling for dmc++ and dmd (for extern(D)), but it should be fixed for dmd. https://issues.dlang.org/show_bug.cgi?id=19785
 Now the fact that 
 "42" is just ignored in the declaration below is indistinguishable from
conspiracy:
 
 void fun(int a[42]);
Ironically, it is not ignored in the C++ mangling if it's a ref to int[42].
Apr 02
parent reply Rubn <where is.this> writes:
On Tuesday, 2 April 2019 at 20:43:14 UTC, Walter Bright wrote:
 On 4/2/2019 4:05 AM, Andrei Alexandrescu wrote:
 You forgot to mention that top-level "const" is ignored in 
 function parameters (for the signature and mangling but not 
 the implementation).
Curiously, it is present in the name mangling for dmc++ and dmd (for extern(D)), but it should be fixed for dmd. https://issues.dlang.org/show_bug.cgi?id=19785
 Now the fact that "42" is just ignored in the declaration 
 below is indistinguishable from conspiracy:
 
 void fun(int a[42]);
Ironically, it is not ignored in the C++ mangling if it's a ref to int[42].
Not ironically, because you can't have a reference to a pointer :). It makes sense if you understand that: void foo( int a[] ); Is not a parameter to an array. After your whole spiel about ferraris, engines, and how their users won't see the internal workings of the engine. I'd have hoped better from you than you pointing at the top level fluffy user-friendly error message and saying LOOK LOOK it says array so it must be an array!
Apr 03
parent reply Rubn <where is.this> writes:
On Wednesday, 3 April 2019 at 20:10:08 UTC, Rubn wrote:
 On Tuesday, 2 April 2019 at 20:43:14 UTC, Walter Bright wrote:
 On 4/2/2019 4:05 AM, Andrei Alexandrescu wrote:
 You forgot to mention that top-level "const" is ignored in 
 function parameters (for the signature and mangling but not 
 the implementation).
Curiously, it is present in the name mangling for dmc++ and dmd (for extern(D)), but it should be fixed for dmd. https://issues.dlang.org/show_bug.cgi?id=19785
 Now the fact that "42" is just ignored in the declaration 
 below is indistinguishable from conspiracy:
 
 void fun(int a[42]);
Ironically, it is not ignored in the C++ mangling if it's a ref to int[42].
Not ironically, because you can't have a reference to a pointer :). It makes sense if you understand that: void foo( int a[] ); Is not a parameter to an array. After your whole spiel about ferraris, engines, and how their users won't see the internal workings of the engine. I'd have hoped better from you than you pointing at the top level fluffy user-friendly error message and saying LOOK LOOK it says array so it must be an array!
A pointer to a reference*.
Apr 03
parent reply Rose <rose sarajevo.com> writes:
On Wednesday, 3 April 2019 at 20:11:02 UTC, Rubn wrote:
 On Wednesday, 3 April 2019 at 20:10:08 UTC, Rubn wrote:
 On Tuesday, 2 April 2019 at 20:43:14 UTC, Walter Bright wrote:
 On 4/2/2019 4:05 AM, Andrei Alexandrescu wrote:
 You forgot to mention that top-level "const" is ignored in 
 function parameters (for the signature and mangling but not 
 the implementation).
Curiously, it is present in the name mangling for dmc++ and dmd (for extern(D)), but it should be fixed for dmd. https://issues.dlang.org/show_bug.cgi?id=19785
 Now the fact that "42" is just ignored in the declaration 
 below is indistinguishable from conspiracy:
 
 void fun(int a[42]);
Ironically, it is not ignored in the C++ mangling if it's a ref to int[42].
Not ironically, because you can't have a reference to a pointer :). It makes sense if you understand that: void foo( int a[] ); Is not a parameter to an array. After your whole spiel about ferraris, engines, and how their users won't see the internal workings of the engine. I'd have hoped better from you than you pointing at the top level fluffy user-friendly error message and saying LOOK LOOK it says array so it must be an array!
A pointer to a reference*.
The Dunning-Kruger is strong with this one. Arrogance completes ignorance.
Apr 03
parent Rubn <where is.this> writes:
On Wednesday, 3 April 2019 at 20:28:35 UTC, Rose wrote:
 On Wednesday, 3 April 2019 at 20:11:02 UTC, Rubn wrote:
 On Wednesday, 3 April 2019 at 20:10:08 UTC, Rubn wrote:
 On Tuesday, 2 April 2019 at 20:43:14 UTC, Walter Bright wrote:
 On 4/2/2019 4:05 AM, Andrei Alexandrescu wrote:
 You forgot to mention that top-level "const" is ignored in 
 function parameters (for the signature and mangling but not 
 the implementation).
Curiously, it is present in the name mangling for dmc++ and dmd (for extern(D)), but it should be fixed for dmd. https://issues.dlang.org/show_bug.cgi?id=19785
 Now the fact that "42" is just ignored in the declaration 
 below is indistinguishable from conspiracy:
 
 void fun(int a[42]);
Ironically, it is not ignored in the C++ mangling if it's a ref to int[42].
Not ironically, because you can't have a reference to a pointer :). It makes sense if you understand that: void foo( int a[] ); Is not a parameter to an array. After your whole spiel about ferraris, engines, and how their users won't see the internal workings of the engine. I'd have hoped better from you than you pointing at the top level fluffy user-friendly error message and saying LOOK LOOK it says array so it must be an array!
A pointer to a reference*.
The Dunning-Kruger is strong with this one. Arrogance completes ignorance.
Not as much as walter and andrei. I really hope I never reach a point where I think I know more than anyone else that I would simply dismiss people's discussions because of some accomplishment. If you think you have nothing more to learn, then step aside for those that do.
Apr 03
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, Apr 2, 2019 at 4:10 AM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 4/2/19 4:11 AM, Walter Bright wrote:
 On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection.
You forgot to mention that top-level "const" is ignored in function parameters (for the signature and mangling but not the implementation).
Actually, it's sadly not ignored, and MSVC mangles it! It's been a massive PITA when writing some of the STL bindings in druntime! I've had to manually build mangled function names to extern, because I can't express it in D >_< https://github.com/dlang/druntime/blob/master/src/core/stdcpp/allocator.d#L50 <- you're loving it!
Apr 04
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/4/19 4:33 AM, Manu wrote:
 On Tue, Apr 2, 2019 at 4:10 AM Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 4/2/19 4:11 AM, Walter Bright wrote:
 On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection.
You forgot to mention that top-level "const" is ignored in function parameters (for the signature and mangling but not the implementation).
Actually, it's sadly not ignored, and MSVC mangles it!
I'd be surprised. It would be a gross bug. It didn't in 2004 when I still was using it. Herb advocates using top-level const in implementation, pointing out that it's ignored in the signature.
 It's been a
 massive PITA when writing some of the STL bindings in druntime!
 I've had to manually build mangled function names to extern, because I
 can't express it in D >_<
 
 https://github.com/dlang/druntime/blob/master/src/core/stdcpp/allocator.d#L50
   <- you're loving it!
Could that be a "pointer to const"? That's not top-level.
Apr 04
parent reply Manu <turkeyman gmail.com> writes:
On Thu, Apr 4, 2019 at 4:15 AM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 4/4/19 4:33 AM, Manu wrote:
 On Tue, Apr 2, 2019 at 4:10 AM Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 4/2/19 4:11 AM, Walter Bright wrote:
 On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection.
You forgot to mention that top-level "const" is ignored in function parameters (for the signature and mangling but not the implementation).
Actually, it's sadly not ignored, and MSVC mangles it!
I'd be surprised. It would be a gross bug. It didn't in 2004 when I still was using it. Herb advocates using top-level const in implementation, pointing out that it's ignored in the signature.
Herb appears to be wrong. And this is his native STL, he should know ;)
 It's been a
 massive PITA when writing some of the STL bindings in druntime!
 I've had to manually build mangled function names to extern, because I
 can't express it in D >_<

 https://github.com/dlang/druntime/blob/master/src/core/stdcpp/allocator.d#L50
   <- you're loving it!
Could that be a "pointer to const"? That's not top-level.
Straight from the STL: xmemory0:989 template<class _Ty> class allocator { // generic allocator for objects of class _Ty public: ... void deallocate(_Ty * const _Ptr, const size_t _Count) { // deallocate object at _Ptr // no overflow check on the following multiply; we assume _Allocate did that check _Deallocate<_New_alignof<_Ty>>(_Ptr, sizeof(_Ty) * _Count); } } I spent hours trying to work out why the mangling was failing before I noticed the const was in the wrong place in the C++ code. Only solution is the code I linked above. Also, FWIW, I think this is a fairly recent change (ie, last 5 years).
Apr 04
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/4/19 1:20 PM, Manu wrote:
 Also, FWIW, I think this is a fairly recent change (ie, last 5 years).
Good to know, thanks! Found this, too: https://stackoverflow.com/questions/32447978/odd-vs-name-mangling-behavior/32448512 I'll email Herb.
Apr 04
parent reply Herb Sutter <hsutter microsoft.com> writes:
On Thursday, 4 April 2019 at 17:25:05 UTC, Andrei Alexandrescu 
wrote:
 On 4/4/19 1:20 PM, Manu wrote:
 Also, FWIW, I think this is a fairly recent change (ie, last 5 
 years).
Good to know, thanks! Found this, too: https://stackoverflow.com/questions/32447978/odd-vs-name-mangling-behavior/32448512 I'll email Herb.
Andrei sent me mail and I did a little digging. Much of the following is courtesy Jonathan Caves (thanks Jon!). Pasting what I sent to Andrei with light edits: Short answer: Yes, but most C++ code won't (and doesn't) notice because to see the different mangling you have to declare the function differently in two translation units, *and* have different "first" declarations in those TUs. So this is invisible for any function you declare in a shared header (because everyone sees the same first declaration). And it's invisible when you declare without top-level const and then define with top-level const on a parameter (because everyone uses the first declaration). Longer answer: Yes, this is a long standing known issue – our name decorator was developed long before C++98 codified a lot of stuff. Note that there are two mangling issues involved that come up in your example (or minor variations of it): [dcl.fct]/5 says that function parameters ignore top-level const and treat [] as *:
 After determining the type of each parameter, any parameter of 
 type
 “array of T” or of function type T is adjusted to be “pointer 
 to T”.
 After producing the list of parameter types, any top-level 
 cv-qualifiers
 modifying a parameter type are deleted when forming the 
 function type.
So these are supposed to be equivalent redeclarations of f and g: ~~~ // Case 1 void f(int); void f(int const); // same, redeclaration // Case 2 void g(int*); void g(int[]); // same, redeclaration ~~~ And in VC++ they are correctly equivalent, in the language. However, for name mangling, VC++ selects mangling based on the first declaration it seems, and it does mangle each of these pairs differently, so if two TUs have different first declarations of each of f and g, they can’t link. Again, to make this actually visible to users, they have to see different *first* declarations. For starters that means they’re not using a shared header. I understand that someone you know found it caused trouble with linking foreign code with C++, though presumably that’s because they had to write their own declaration by hand (in C++, or in the other language)? I’ve mostly seen that sort of thing when people have to write their own declarations, and in those cases they also had general fragility (e.g., writing int vs long, that sort of thing – because they have to be careful to get the declarations exactly right because they’re writing them manually, same trouble that Java JNI and .NET P/Invoke have in general, you have to make the parameters perfect). The worry about ‘fixing’ the name decorator is that it would be an ABI breaking change and so we have always be reticent in making any changes. That said, if we had customer examples that this was causing serious problems, we’d consider it. If you have production examples you could share or link to that would be helpful. Mostly, we don’t hear about this and I couldn’t find a report of it in our current online bug tracking systems (but I may have missed it) – most people are like you and rarely notice it even though it’s been like this for ~25 years. :) Because you have to be writing code in a fairly special way, effectively writing somebody else's function declaration by hand instead of using the .h they provided, and write it differently than in that .h, to be able to notice.
Apr 06
parent Manu <turkeyman gmail.com> writes:
On Sat, Apr 6, 2019 at 8:30 AM Herb Sutter via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 4 April 2019 at 17:25:05 UTC, Andrei Alexandrescu
 wrote:
 On 4/4/19 1:20 PM, Manu wrote:
 Also, FWIW, I think this is a fairly recent change (ie, last 5
 years).
Good to know, thanks! Found this, too: https://stackoverflow.com/questions/32447978/odd-vs-name-mangling-behavior/32448512 I'll email Herb.
Andrei sent me mail and I did a little digging. Much of the following is courtesy Jonathan Caves (thanks Jon!). Pasting what I sent to Andrei with light edits: Short answer: Yes, but most C++ code won't (and doesn't) notice because to see the different mangling you have to declare the function differently in two translation units, *and* have different "first" declarations in those TUs. So this is invisible for any function you declare in a shared header (because everyone sees the same first declaration). And it's invisible when you declare without top-level const and then define with top-level const on a parameter (because everyone uses the first declaration). Longer answer: Yes, this is a long standing known issue – our name decorator was developed long before C++98 codified a lot of stuff. Note that there are two mangling issues involved that come up in your example (or minor variations of it): [dcl.fct]/5 says that function parameters ignore top-level const and treat [] as *:
 After determining the type of each parameter, any parameter of
 type
 “array of T” or of function type T is adjusted to be “pointer
 to T”.
 After producing the list of parameter types, any top-level
 cv-qualifiers
 modifying a parameter type are deleted when forming the
 function type.
So these are supposed to be equivalent redeclarations of f and g: ~~~ // Case 1 void f(int); void f(int const); // same, redeclaration // Case 2 void g(int*); void g(int[]); // same, redeclaration ~~~ And in VC++ they are correctly equivalent, in the language. However, for name mangling, VC++ selects mangling based on the first declaration it seems, and it does mangle each of these pairs differently, so if two TUs have different first declarations of each of f and g, they can’t link. Again, to make this actually visible to users, they have to see different *first* declarations. For starters that means they’re not using a shared header. I understand that someone you know found it caused trouble with linking foreign code with C++, though presumably that’s because they had to write their own declaration by hand (in C++, or in the other language)? I’ve mostly seen that sort of thing when people have to write their own declarations, and in those cases they also had general fragility (e.g., writing int vs long, that sort of thing – because they have to be careful to get the declarations exactly right because they’re writing them manually, same trouble that Java JNI and .NET P/Invoke have in general, you have to make the parameters perfect). The worry about ‘fixing’ the name decorator is that it would be an ABI breaking change and so we have always be reticent in making any changes. That said, if we had customer examples that this was causing serious problems, we’d consider it. If you have production examples you could share or link to that would be helpful. Mostly, we don’t hear about this and I couldn’t find a report of it in our current online bug tracking systems (but I may have missed it) – most people are like you and rarely notice it even though it’s been like this for ~25 years. :) Because you have to be writing code in a fairly special way, effectively writing somebody else's function declaration by hand instead of using the .h they provided, and write it differently than in that .h, to be able to notice.
Thanks for the background. For my effort (binding to STL), a bigger problem with MSVC compatibility isn't that this mangling is weird (I have an awkward solution in this case), it's that the MS C++ runtime ABI has historically been somewhat volatile. The significant ABI-breaking change was when allocator<T>::destroy() was changed from `T*` to `T* const`, which appears to have happened perhaps vc2013->2015? (I don't have those old headers on my system anymore to check). There are numerous other cases of ABI breakage, but this one happened to introduce `* const`, which I couldn't express. Fortunately, it seems VS2015 and onward has made greater efforts towards ABI stability, so I plan to simply deprecate distant backwards-compatibility, and hope for a continued commitment from your side ;) For future reference, if you're making this decision about your ABI when authoring the runtime; for foreign languages trying to link to C++, I expect `T*` is generally much simpler. I suspect many FFI's would have trouble with `* const`, and D is one such case. We cross-language linker-er's would certainly appreciate trying to avoid `* const` in public ABI's since MSVC has this odd mangling rule.
Apr 06
prev sibling parent Rubn <where is.this> writes:
On Tuesday, 2 April 2019 at 08:11:31 UTC, Walter Bright wrote:
 On 4/1/2019 5:55 PM, Atila Neves wrote:
 Factually incorrect.
I suspect Rubn has confused the syntactical conflation of arrays with pointers in C, and the implicit coercion of arrays to pointers, as them being the same. They simply aren't the same, as they are semantically separated by one level of indirection.
I have not said they are the same, do regex search of "the same", and you will see only you and someone else have said this formation of words.
 I wrote an article about it calling this "C's Biggest Mistake", 
 as this has led to decades of crashes and malware infestations:

 https://www.digitalmars.com/articles/b44.html
Yes arrays only being able to be represented as pointers is indeed a downfall of C/C++.
Apr 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2019 4:04 PM, Atila Neves wrote:
 It's a good point though that void is 
 treated differently in C's type system.
Void is treated as a degenerate type, and as you say, rejected constructs like arrays of void are rejected because they are nonsense. Arrays of functions are similarly rejected. Not at all like what goes on with ref in C++, because an array of refs could have perfectly reasonable semantics. But they are not allowed in C++, because ref is a storage class pretending to be a type.
Apr 02
parent Rubn <where is.this> writes:
On Tuesday, 2 April 2019 at 08:05:25 UTC, Walter Bright wrote:
 But they [arrays of reference] are not allowed in C++, because 
 ref is a storage class pretending to be a type.
And we've come back fully circle. This is not the reason at all why an array of references is not allowed. You can't have pointers to references, and without pointers you can't have a full array implementation. How much sense would it make if you could only pass an array by reference? Not very much.
Apr 03
prev sibling parent Manu <turkeyman gmail.com> writes:
On Mon, Apr 1, 2019 at 7:00 AM Atila Neves via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Monday, 1 April 2019 at 13:09:28 UTC, Dein wrote:
 On Monday, 1 April 2019 at 01:18:44 UTC, Walter Bright wrote:
 On 3/31/2019 5:35 PM, Rubn wrote:
 you can literally use it everywhere else you can use a type.
No, you can't. An array of refs won't compile, either. void test(int& a[]); // error A C++ ref can only appear at the top of a type AST, which is unlike any other type. Which exactly matches the only place a storage class can be!
Seriously? You should know as well as I do what that function actually translates to: void test(int&* const a); So I ask you now, how do you get a pointer to a reference. Its the exact same thing. Not sure if you are trying to just deceive me with some syntax sugar in C++ or what.
Bad example, but the point stands: ---- // foo.cpp int fun() { int& foo[5]; // doesn't compile } ---- I'd never even thought of it until Walter mentioned it that one can't have an array of references. Huh.
You could totally invent language where that was possible though, and it would be *awesome*!
Apr 04
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2019 6:09 AM, Dein wrote:
 Not sure if you are trying to just deceive me with some syntax sugar in 
 C++ or what.
You can try it yourself: ---------- g++ -c test.cpp test.cpp:1:17: error: cannot declare pointer to int& void test(int&* p); ^ ---------- g++ -c test.cpp test.cpp:1:18: error: declaration of p as array of references void test(int& p[]); ^ ----------
Apr 01
parent reply Rubn <where is.this> writes:
On Monday, 1 April 2019 at 20:37:03 UTC, Walter Bright wrote:
 On 4/1/2019 6:09 AM, Dein wrote:
 Not sure if you are trying to just deceive me with some syntax 
 sugar in C++ or what.
You can try it yourself: ---------- g++ -c test.cpp test.cpp:1:17: error: cannot declare pointer to int& void test(int&* p); ^ ---------- g++ -c test.cpp test.cpp:1:18: error: declaration of p as array of references void test(int& p[]); ^ ----------
You can try it yourself: void foo(int* const p) {} void foo(int p[]) {} ----------------------------------------------- test.cpp:3:6: error: redefinition of 'foo' void foo(int p[]) {} ^ test.cpp:2:6: note: previous definition is here void foo(int* const p) {} ^ 1 error generated.
Apr 01
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/19 7:43 PM, Rubn wrote:
 On Monday, 1 April 2019 at 20:37:03 UTC, Walter Bright wrote:
 On 4/1/2019 6:09 AM, Dein wrote:
 Not sure if you are trying to just deceive me with some syntax sugar 
 in C++ or what.
You can try it yourself: ---------- g++ -c test.cpp test.cpp:1:17: error: cannot declare pointer to int&  void test(int&* p);                  ^ ----------  g++ -c test.cpp test.cpp:1:18: error: declaration of p as array of references  void test(int& p[]);                   ^ ----------
You can try it yourself: void foo(int* const p) {} void foo(int p[]) {} ----------------------------------------------- test.cpp:3:6: error: redefinition of 'foo' void foo(int p[]) {}      ^ test.cpp:2:6: note: previous definition is here void foo(int* const p) {}      ^ 1 error generated.
The fact that we have somebody teaching Walter Bright the C language to is supremely ironic in wake of the recent discussions.
Apr 01
next sibling parent Rubn <where is.this> writes:
On Tuesday, 2 April 2019 at 00:13:13 UTC, Andrei Alexandrescu 
wrote:
 On 4/1/19 7:43 PM, Rubn wrote:
 On Monday, 1 April 2019 at 20:37:03 UTC, Walter Bright wrote:
 On 4/1/2019 6:09 AM, Dein wrote:
 Not sure if you are trying to just deceive me with some 
 syntax sugar in C++ or what.
You can try it yourself: ---------- g++ -c test.cpp test.cpp:1:17: error: cannot declare pointer to int&  void test(int&* p);                  ^ ----------  g++ -c test.cpp test.cpp:1:18: error: declaration of p as array of references  void test(int& p[]);                   ^ ----------
You can try it yourself: void foo(int* const p) {} void foo(int p[]) {} ----------------------------------------------- test.cpp:3:6: error: redefinition of 'foo' void foo(int p[]) {}      ^ test.cpp:2:6: note: previous definition is here void foo(int* const p) {}      ^ 1 error generated.
The fact that we have somebody teaching Walter Bright the C language to is supremely ironic in wake of the recent discussions.
Guess he's spent too much time in the D he's become a bit rust-y..
Apr 01
prev sibling next sibling parent Frank Fuente <frfu anywhere.com> writes:
On Tuesday, 2 April 2019 at 00:13:13 UTC, Andrei Alexandrescu 
wrote:
 On 4/1/19 7:43 PM, Rubn wrote:
 On Monday, 1 April 2019 at 20:37:03 UTC, Walter Bright wrote:
 [...]
You can try it yourself: void foo(int* const p) {} void foo(int p[]) {} ----------------------------------------------- test.cpp:3:6: error: redefinition of 'foo' void foo(int p[]) {}      ^ test.cpp:2:6: note: previous definition is here void foo(int* const p) {}      ^ 1 error generated.
The fact that we have somebody teaching Walter Bright the C language to is supremely ironic in wake of the recent discussions.
Here's an egg and this is how you suck it...
Apr 02
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 2 April 2019 at 00:13:13 UTC, Andrei Alexandrescu 
wrote:
 On 4/1/19 7:43 PM, Rubn wrote:
 On Monday, 1 April 2019 at 20:37:03 UTC, Walter Bright wrote:
 [...]
You can try it yourself: void foo(int* const p) {} void foo(int p[]) {} ----------------------------------------------- test.cpp:3:6: error: redefinition of 'foo' void foo(int p[]) {}      ^ test.cpp:2:6: note: previous definition is here void foo(int* const p) {}      ^ 1 error generated.
The fact that we have somebody teaching Walter Bright the C language to is supremely ironic in wake of the recent discussions.
+1000! But at least it's funny! :-P
Apr 02
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Mar 29, 2019 at 9:10 AM Victor Porton via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 That `ref T` (where T is a type) is not a type is a serious
 design error, because so `ref T` cannot be used as a template
 argument.

 It is a very serious problem.

 Even in C++ despite of all its silliness, T& is a type and can be
 used as a template argument.

 Can the language be changed to resolve this problem?
1. I couldn't possibly agree with you more!!! Sadly that's not how it is. 2. You can use `auto ref` on function arguments of template functions to capture the ref-ness of the calling argument: void fun(T)(auto ref T arg) 3. I have often deployed something like this (I just typed this in the email as example, I have no idea if this compiles or runs): Ref(T) { T* value; this(ref T val) { value = &val; } ref T opAssign(U)(auto ref U rh) { *value = rh; } ref T get() { return *value; } inout; alias get this; } ... template isRef(T) = is(T == Ref!U, U); void fun(T)(T arg) { pragma(msg, isRef!T ? "is a ref" : "not a ref"); } int i; auto ri = Ref!int(i); fun(i); // > "not a ref" fun(ri); // > "is a ref" Writing that code is like stabbing myself in the hands with rusty forks... I feel emotionally unstabilised, but it can solve your problems in various applications.
Mar 31
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2019 3:48 PM, Manu wrote:
 Even in C++ despite of all its silliness, T& is a type and can be
 used as a template argument.

 Can the language be changed to resolve this problem?
1. I couldn't possibly agree with you more!!! Sadly that's not how it is.
Although ref can be captured with C++ templates, it isn't really a type. For example, you cannot create a pointer to a ref. Furthermore, the spec for it is crammed with wacky special cases to make it behave like a storage class instead of a type. I defy anyone to give a list of cases when C++ ref is inferred and when it is not, and if anyone did, I'm sure it would be wrong. Yes, it's that bad.
 Writing that code is like stabbing myself in the hands with rusty
 forks...
I'm convinced that if C++ ref didn't exist, and we added it to D, you'd hate it :-)
 I feel emotionally unstabilised, but it can solve your
 problems in various applications.
Please show a use case. I can't think of one.
Mar 31
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Mar 31, 2019 at 5:20 PM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 3/31/2019 3:48 PM, Manu wrote:
 Even in C++ despite of all its silliness, T& is a type and can be
 used as a template argument.

 Can the language be changed to resolve this problem?
1. I couldn't possibly agree with you more!!! Sadly that's not how it is.
Although ref can be captured with C++ templates, it isn't really a type. For example, you cannot create a pointer to a ref. Furthermore, the spec for it is crammed with wacky special cases to make it behave like a storage class instead of a type. I defy anyone to give a list of cases when C++ ref is inferred and when it is not, and if anyone did, I'm sure it would be wrong. Yes, it's that bad.
Are you saying that it's impossible to design a solution where ref is part of the type and that's less complex than C++? Is the complexity is that ecosystem inherent, or is it somewhat informed by backwards-compatibility, and other C++ design constraints? The fact that I can write `struct Ref(T)` and that it propagates the type system in a natural way suggests to me that the design is not impossible.
 Writing that code is like stabbing myself in the hands with rusty
 forks...
I'm convinced that if C++ ref didn't exist, and we added it to D, you'd hate it :-)
I think you probably have me backwards... irrespective of C++, and there was some discussion about ref vs pointers, I would push 110% for ref and eliminate pointers entirely. I would be much happier to write this hack in the event I need a pointer, than to hack around ref as I do today: struct Pointer(T) { size_t addr; this(ref T val) { addr = __traits(addressOf, val); } ref T get() { return __traits(addressAsRef, T, addr); } alias get this; Pointer!T opBinary(string op : "+")(size_t offset) { Pointer!T r; r.addr = addr + offset * T.sizeof; return r; } // etc... } Pointers are mostly useless and unsafe at best, especially when arrays are a first-class type.
 I feel emotionally unstabilised, but it can solve your
 problems in various applications.
Please show a use case. I can't think of one.
A use case for propagating ref in the type? You can't imagine why a template argument might want to distinguish `int` and `ref int`? I don't know how you've never found yourself static-if-ing on ref-ness of stuff in every bit of functional meta you've ever written. Ref creates an out-of-language (we have no language features to interact with 'storage class') suite of conditions that I frequently have to wrangle my way through. We have strong language mechanisms to reason about the type system, there is no language to reason about storage class that's not a kludge of awkward hacks and ugly meta utilities.
Mar 31
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2019 6:19 PM, Manu wrote:
 Are you saying that it's impossible to design a solution where ref is
 part of the type and that's less complex than C++?
I couldn't think of a way. I could have simply copied the C++ design. But why copy a nightmare of kludges?
 Is the complexity is that ecosystem inherent, or is it somewhat
 informed by backwards-compatibility, and other C++ design constraints?
There was no backwards compatibility issue when ref was designed. It's just a poor choice (like volatile).
 The fact that I can write `struct Ref(T)` and that it propagates the
 type system in a natural way suggests to me that the design is not
 impossible.
I have no idea why you want to do such things, but apparently you have a solution that works for you, so that's all good.
 Please show a use case. I can't think of one.
A use case for propagating ref in the type? You can't imagine why a template argument might want to distinguish `int` and `ref int`?
Indulge me. Why would it?
 I don't know how you've never found yourself static-if-ing on ref-ness
 of stuff in every bit of functional meta you've ever written. Ref
 creates an out-of-language (we have no language features to interact
 with 'storage class') suite of conditions that I frequently have to
 wrangle my way through.
 We have strong language mechanisms to reason about the type system,
 there is no language to reason about storage class that's not a kludge
 of awkward hacks and ugly meta utilities.
If I was faced with that, I'd step back and re-assess why the design required such machinations. It reminds me of when I peruse Phobos, I'm disturbed by the overly complex code there - something Andrei referred to in the "generality creep" thread. If C++ does it better, I don't see how. I find the implementation code of the STL to be horrifying in its complexity. I don't know how to write such code without thinking "something has gone terribly wrong". If I may, I once talked to a Ferrari mechanic. He said that most engines inside, where customers didn't see the innards, were sloppily made. But that the Ferrari engine was a thing of beauty inside and a joy to work on. Ironically, Ferraris are also known for cheap, poorly done cab interiors. An unusual focus for a car company :-) but one that appeals to my inner engineer. The engine in my Dodge was built the same way, it's blueprinted with all top quality parts inside it, but the outside is plain jane, no chrome parts, no dress-up, etc.
Apr 01
next sibling parent Rubn <where is.this> writes:
On Monday, 1 April 2019 at 11:09:01 UTC, Walter Bright wrote:
 If I may, I once talked to a Ferrari mechanic. He said that 
 most engines inside, where customers didn't see the innards, 
 were sloppily made. But that the Ferrari engine was a thing of 
 beauty inside and a joy to work on. Ironically, Ferraris are 
 also known for cheap, poorly done cab interiors. An unusual 
 focus for a car company :-) but one that appeals to my inner 
 engineer. The engine in my Dodge was built the same way, it's 
 blueprinted with all top quality parts inside it, but the 
 outside is plain jane, no chrome parts, no dress-up, etc.
So your mechanic friend is comparing hand-built and individually tuned super-sport performance Ferraris to mass produced production-line commuter cars? When you don't have to focus on practicality with an inflated price tag you aren't limited with how you design your vehicle. You will be overpaying for maintenance costs though. I really doubt your Dodge engine was built the same way as a Ferrari's was unless maybe you are driving around a Dodge Viper. Please tell me your not one of those people that drive around a truck. American brand vehicles (yes not only cars) aren't well known for their reliability either.
Apr 01
prev sibling parent Manu <turkeyman gmail.com> writes:
On Mon, Apr 1, 2019 at 4:10 AM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 3/31/2019 6:19 PM, Manu wrote:
 Are you saying that it's impossible to design a solution where ref is
 part of the type and that's less complex than C++?
I couldn't think of a way. I could have simply copied the C++ design. But why copy a nightmare of kludges?
 Is the complexity is that ecosystem inherent, or is it somewhat
 informed by backwards-compatibility, and other C++ design constraints?
There was no backwards compatibility issue when ref was designed. It's just a poor choice (like volatile).
 The fact that I can write `struct Ref(T)` and that it propagates the
 type system in a natural way suggests to me that the design is not
 impossible.
I have no idea why you want to do such things, but apparently you have a solution that works for you, so that's all good.
 Please show a use case. I can't think of one.
A use case for propagating ref in the type? You can't imagine why a template argument might want to distinguish `int` and `ref int`?
Indulge me. Why would it?
Propagating compile time information as types is the fundamental of D's meta. Not being able to propagate ref's is really problematic. Not being able to declare a local ref is really problematic. void fun(ref int x) { bool b = is(typeof(x) == ref); // nope! seems so obvious (you should watch their faces when I show them how to do it) int i = 10; ref int j = i; // nope! again, watch their faces when I say they can't do this ref auto resolveLongExpression = long.expression().that[0].we().dont_want_to.repeat; // nope! foreach(i; things) { resolveLongExpression++; // repeated access to a deep expression // use a pointer you say? pointers change semantics; assignment and increment mean something different now // if there's any meta involved, then pointer's semantic distinction is something you're gonna have to write `static if()` nonsense to detect and special-case! } // other kinds of expressions that we don't want to repeat, but may want to carry the ref-ness auto ref x = returnsValue(); ++x; // increment local auto ref y = returnsRef(); ++y; // increment reference } alias Param = Parameters!(fun)[0]; void g(Param arg) // nope! { ... lots of code } this is obviously much better: bool isRef(alias fn, int argIndex, int i = 0) { static if (i == __traits(getParameterStorageClasses, fn, argIndex).length) enum isRef = false; else enum isRef = __traits(getParameterStorageClasses, fn, argIndex)[i] == "ref" ? true : isRef!(fn, argIndex, i + 1); } string myFun = "void g(" ~ (isRef!(fun, 0) ? "ref " : "") ~ "Param arg)\n" ~ "{\n" ~ " lots;\n" ~ " of;\n" ~ " code;\n" ~ "}\n"; mixin (myFun); Whole function (or any other construction that fits this pattern) is a string because some storage class appears in the declaration. Say goodbye to autocomplete, debugging, refactoring, syntax highlighting, readability, and editability/maintainability. Sorry, I don't have a real-world case at hand right now, I didn't start the thread complaining this time; I'm just supporting someone who is feeling the same feels. I've learned to try and avoid this stuff in D, because D just can't reasonably do it. But it's very annoying to avoid, and it's a major weakness of D's meta, and it's very disappointing to new users when they work this out.
 I don't know how you've never found yourself static-if-ing on ref-ness
 of stuff in every bit of functional meta you've ever written. Ref
 creates an out-of-language (we have no language features to interact
 with 'storage class') suite of conditions that I frequently have to
 wrangle my way through.
 We have strong language mechanisms to reason about the type system,
 there is no language to reason about storage class that's not a kludge
 of awkward hacks and ugly meta utilities.
If I was faced with that, I'd step back and re-assess why the design required such machinations.
This is like a general argument against meta-programming. You don't get to decide when this stuff comes up in the wild; it just does. The worst cases are usually when automating bindings between systems; that might be to foreign languages, scripting solutions, tooling/editor interactions, or perhaps some high-level application scaffolding. One of D's biggest attractions is the ability to use powerful in-language meta-programming features to solve binding and boilerplate tasks that would traditionally require external tooling. When I use D, I lean into that promise HARD. The reason to choose D is to solve particular categories of problems I can't possibly solve in other languages. Ref (and other storage classes) bite me in the arse every single time. Imagine how much worse this will be when 'scope' proliferates!
 It reminds me of when I peruse Phobos, I'm disturbed by the overly complex code
 there - something Andrei referred to in the "generality creep" thread.
I'm not commenting on phobos complexity (which is indeed hideous, and I avoid phobos). There are a lot of programming tasks; one programming task is writing programs, but another overwhelmingly popular and most tedious and painful task is developing and maintaining bindings and boilerplate interaction to large established ecosystems. Basically everyone I know who has been drawn to D are initially attracted by the ability to automate boilerplate and terrible cruft from external tooling and reducing build complexity. That's the stuff that sends them packing in search of a brighter future. A lot of meta is used to automate boilerplate and binding machinery. If a user is 'just writing programs', then C++ is just fine. They're attracted to D by the promise of simplifying or addressing the mountain of code that C++ _can't_ express. Boilerplate meta is one of the most common tasks that stokes initial interest in D. To dismiss that, is to misunderstand D's value proposition to a huge audience. This is certainly the case where D is discussed in the project I'm work on right now, and has been the case since I ever started discussing D with colleagues. It's the most immediate and painful problem they see an obvious solution for. You should value that use-case if you want to attract users. Everything else D has to offer is a nice bonus that these people would appreciate in time, but they need to be drawn in by successfully solving the problems immediately before them that D appears to be well-placed to solve. I have watched so many cases of people trying out some such solution, and then they encounter ref, I start to explain to them what they need to do, they are surprised, then they're angry at me for wasting their time, and then they lose interest. Storage class is really, *really* bad. The terribleness of it in terms of the impression it leaves on people is really important. I've been trying to tell you this for so long, I don't think there's anything else I can do.
 If C++ does it better, I don't see how. I find the implementation code of the
 STL to be horrifying in its complexity. I don't know how to write such code
 without thinking "something has gone terribly wrong".
It's not about STL. I hope I've made that clear. But that said, you have invented the most powerful meta-programming language out there, you've gotta own that, and you can't be upset when people try to apply it to solve specific problems it's uniquely well-fit for. I agree there's a HUGE danger of abusing D's meta-programming features, I constantly have to restrain myself, but the kind of work I refer to is not of that kind.
 If I may, I once talked to a Ferrari mechanic. He said that most engines
inside,
 where customers didn't see the innards, were sloppily made. But that the
Ferrari
 engine was a thing of beauty inside and a joy to work on. Ironically, Ferraris
 are also known for cheap, poorly done cab interiors. An unusual focus for a car
 company :-) but one that appeals to my inner engineer. The engine in my Dodge
 was built the same way, it's blueprinted with all top quality parts inside it,
 but the outside is plain jane, no chrome parts, no dress-up, etc.
That's a nice thought, but that's not important to this particular class of problem. What I'm talking about here is attracting users who are able to successfully solve their long-standing and terribly painful problems. Cases where storage class comes up as a problem is almost always of that category. Apparently I seem to suffer this category of task 10x more than the average guy. I've tried to make this point before, and I'll try again; Most programmers are not 'great' programmers, they're just programmers, they're employees of businesses, at 5pm they go home and hang out with the kids and shag the wife. They're not too worried about building a ferrari engine; they mostly just wanna get paid, they have a job to do, and they almost invariably have an established ecosystem of existing cruft they interact with. There is a high probability they have this rats-next of hand-maintained boilerplate and tooling that they HATE maintaining, and that's the angle I've continually had the most success gaining interest from new users. Our goal is to attract these people, and ideally, improve their ability to do a good job more quickly. We want them to feel more productive and make less mistakes, but we can't help them if they never come to the party! D's key advantage out-of-the-gate as I have seen it for so many years, is that it's *theoretically* possible to build bridges between existing ecosystems where we can take a foothold against 40 years of establishment. This is the land of boilerplate and connective meta. I've written a lot of it. They won't come to us if they need to swim the crocodile infested river. We must build a bridge to them and make crossing the river unreasonably simple and appear like the obvious thing to do. Storage class hurts more than anything else towards this end. Anyway... I'm going to bed. I'll complain about it again next year.
Apr 04
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 1 April 2019 at 01:19:41 UTC, Manu wrote:
 On Sun, Mar 31, 2019 at 5:20 PM Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On 3/31/2019 3:48 PM, Manu wrote:
<snip> I don't know how you've never found yourself static-if-ing on ref-ness of stuff in every bit of functional meta you've ever written. Ref creates an out-of-language (we have no language features to interact with 'storage class') suite of conditions that I frequently have to wrangle my way through.
One can inspect the ref-ness of function parameters: --------------- void main() { fun(5); int i; fun(i); } void fun(T)(auto ref T value) { import std.stdio; writeln("T: ", T.stringof, " ref? ", __traits(isRef, value)); } --------------- Output: T: int ref? false T: int ref? true Unfortunately for me, this is a thing though: https://issues.dlang.org/show_bug.cgi?id=19507 *I* think that's a bug (which is why I filed it), but I'm not even sure.
Apr 01
prev sibling next sibling parent reply David Bennett <davidbennett bravevision.com> writes:
On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 Can the language be changed to resolve this problem?
Currently working on a project that works with a lot on pointers to fixed length arrays and its currently very easy to forget to de-refrence the pointer because the pointer and array syntax is the same. For example I have code that looks something like this: --- float[32]* myarray = magicFunction(); foreach(el; myarray[0]){ } --- But something like this would me much less prone to error (ie missing the [0] above): --- ref float[32] myarray = magicFunction(); foreach(el; myarray){ } --- If i convert the above code to use slices I loose the compile-time bounds check.
Mar 31
parent ag0aep6g <anonymous example.com> writes:
On 01.04.19 05:38, David Bennett wrote:
 ---
 
      float[32]* myarray = magicFunction();
 
      foreach(el; myarray[0]){
 
      }
 ---
Aside: Is there are reason why you're writing `myarray[0]` instead of `*myarray`? Looks odd.
 But something like this would me much less prone to error (ie missing 
 the [0] above):
 
 ---
 
      ref float[32] myarray = magicFunction();
 
      foreach(el; myarray){
 
      }
 ---
If you simply forget the `[0]` (or `*`), the code doesn't compile. So that specific mistake can't do any real damage. Doesn't seem like a good example to motivate making the language more complex.
Apr 01
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious 
 design error,
No.
 It is a very serious problem.
No.
 Can the language be changed to resolve this problem?
There is no reason to do so.
Apr 01
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Apr 1, 2019 at 4:25 PM Guillaume Piolat via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious
 design error,
No.
 It is a very serious problem.
No.
 Can the language be changed to resolve this problem?
There is no reason to do so.
I hope I've made my case... again.
Apr 04
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/4/19 4:28 AM, Manu wrote:
 On Mon, Apr 1, 2019 at 4:25 PM Guillaume Piolat via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Friday, 29 March 2019 at 16:06:09 UTC, Victor Porton wrote:
 That `ref T` (where T is a type) is not a type is a serious
 design error,
No.
 It is a very serious problem.
No.
 Can the language be changed to resolve this problem?
There is no reason to do so.
I hope I've made my case... again.
It's a problem we don't have a clear vision in the community on at least the obvious matters. Reference types are recognized even within C++ as ho-hum. These debates are also a time-waster, collectively and cumulatively many hours have been spent on this and of course nobody "got convinced" of anything. There are many areas that are positively in need of and receptive to improvement. If only that enthusiasm was channeled that direction...
Apr 04