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/

Nice tip!

One typo:

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

should be

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


Arredondo.

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

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;
}

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-read-error-messages/ 
> 
> 
> Reddit:
> https://www.reddit.com/r/programming/comments/8l1a8u/prefer_alias_this_over_alias_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

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?)

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?

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...

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

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.