www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Complicated Types: Prefer =?UTF-8?B?4oCcYWxpYXMgdGhpc+KAnQ==?= Over

reply Mike Parker <aldacron gmail.com> writes:
Nick Sabaluasky's first post to the D Blog is a tip on how to 
create an aliased type that keeps its name in error messages.

The blog:
https://dlang.org/blog/2018/05/21/complicated-types-prefer-alias-this-over-alias-for-easier-to-read-error-messages/

Reddit:
https://www.reddit.com/r/programming/comments/8l1a8u/prefer_alias_this_over_alias_for_easiertoread/
May 21 2018
next sibling parent Arredondo <arm.plus gmail.com> writes:
Nice tip!

One typo:


1. Although the alias this means MyType...


should be


2. Although the alias this means MyType...



Arredondo.
May 21 2018
prev sibling next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Monday, 21 May 2018 at 14:48:23 UTC, Mike Parker wrote:

 Nick Sabaluasky's first post to the D Blog is a tip on how to 
 create an aliased type that keeps its name in error messages.


Nice. Interestingly, the error message references the wrong type 
when trying to access static members:

struct MT {
     int _payload;
     alias _payload this;
}

unittest {
     MT a;
     a.foo = 3;  // Error: no property foo for type MT
     MT.foo = 3; // Error: no property foo for type int
}

https://issues.dlang.org/show_bug.cgi?id=18892

--
   Simen
May 21 2018
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 21 May 2018 at 14:48:23 UTC, Mike Parker wrote:

 Nick Sabaluasky's first post to the D Blog is a tip on how to 
 create an aliased type that keeps its name in error messages.


I'm not sure making `_data` private is really a good idea. For 
example, this only works if `_data` is public:

import std.algorithm;
import std.range;
import std.stdio;

struct MyType
{
	auto _data = iota(10);
	alias _data this;
}

void main()
{
	MyType x;
	x.each!writeln;
}
May 21 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/21/2018 01:30 PM, Paul Backus wrote:

 
 I'm not sure making `_data` private is really a good idea. For example, 
 this only works if `_data` is public:
 
 import std.algorithm;
 import std.range;
 import std.stdio;
 
 struct MyType
 {
      auto _data = iota(10);
      alias _data this;
 }
 
 void main()
 {
      MyType x;
      x.each!writeln;
 }


Ouch, and the error message isn't very helpful either. I wonder what 
causes this to fail though, and whether it might simply be a compiler bug?
May 21 2018
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/21/18 4:29 PM, Nick Sabalausky (Abscissa) wrote:

 On 05/21/2018 01:30 PM, Paul Backus wrote:

 I'm not sure making `_data` private is really a good idea. For 
 example, this only works if `_data` is public:

 import std.algorithm;
 import std.range;
 import std.stdio;

 struct MyType
 {
      auto _data = iota(10);
      alias _data this;
 }

 void main()
 {
      MyType x;
      x.each!writeln;
 }


 
 Ouch, and the error message isn't very helpful either. I wonder what 
 causes this to fail though, and whether it might simply be a compiler bug?


No, an alias to private data doesn't magically make it public.

The reason it doesn't work is that each is in std.algorithm.iteration, 
which has no visibility into private symbols of your main module.

This also fails:

assert(isInputRange!MyType);

-Steve
May 21 2018
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 21 May 2018 at 20:29:26 UTC, Nick Sabalausky 
(Abscissa) wrote:

 Ouch, and the error message isn't very helpful either. I wonder 
 what causes this to fail though, and whether it might simply be 
 a compiler bug?


I'm pretty sure it's intended behavior. Templates are 
instantiated in the same module they're declared in [1], so since 
`_data` isn't visible in `std.algorithm`, `each` can't see it.

It's arguable that there ought to be an exception for `alias 
this`, but I expect that kind of change would require a DIP.

[1]: https://dlang.org/spec/template.html#instantiation_scope
May 22 2018
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/21/18 10:48 AM, Mike Parker wrote:

 Nick Sabaluasky's first post to the D Blog is a tip on how to create an 
 aliased type that keeps its name in error messages.
 
 The blog:
 https://dlang.org/blog/2018/05/21/complicated-types-prefer-alias-this-over-alias-for-easier-to-
ead-error-messages/ 
 
 
 Reddit:
 https://www.reddit.com/r/programming/comments/8l1a8u/prefer_alias_this_over_ali
s_for_easiertoread/ 
 


The list has two "1." headers.

Nice idea, I wonder if the compiler couldn't do this automatically with 
alias, however. It already does this in some cases (e.g. string instead 
of immutable(char)[]).

This would help solve the problem that error messages aren't going to 
get better when you pass it into something that only accepts the aliased 
type. However, for the most part, these are non-template functions anyway.

-Steve
May 21 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/21/2018 12:36 PM, Arredondo wrote:

 One typo:


 1. Although the alias this means MyType...
 2. Although the alias this means MyType...




On 05/21/2018 01:43 PM, Steven Schveighoffer wrote:

 The list has two "1." headers.


Looks like the blog software got confused by my multi-paragraph "1. " 
(Maybe that's not strictly kosher from a writing perspective anyway?)
May 21 2018
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 21 May 2018 at 20:22:05 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 05/21/2018 12:36 PM, Arredondo wrote:

 One typo:


 1. Although the alias this means MyType...
 2. Although the alias this means MyType...






Sheesh. I stared at this for a bit, thinkking, "But that's the 
same thing!" My eyes kept sliding right past the item numbers, 
here and in the post.


 On 05/21/2018 01:43 PM, Steven Schveighoffer wrote:

 The list has two "1." headers.


 Looks like the blog software got confused by my multi-paragraph 
 "1. " (Maybe that's not strictly kosher from a writing 
 perspective anyway?)



GitHub got the item numbers right in the gist we used for 
editing, though the formatting of the extra paragraphs wrong. It 
was multimarkdown that goofed it. WP does support Markdown for 
posting, but I've been unable to enable it on this installation, 
so I run everything through multimarkdown first.
May 21 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/21/2018 01:43 PM, Steven Schveighoffer wrote:

 Nice idea, I wonder if the compiler couldn't do this automatically with 
 alias, however. It already does this in some cases (e.g. string instead 
 of immutable(char)[]).
 
 This would help solve the problem that error messages aren't going to 
 get better when you pass it into something that only accepts the aliased 
 type. However, for the most part, these are non-template functions anyway.


That was discussed and rejected some years ago. IIRC, Walter just didn't 
like it.

I'd certainly be in favor of it though. But in lieu of that...
May 21 2018