Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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.
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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...
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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?
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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?)
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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;
}
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
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
Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages
Nice tip! One typo: 1. Although the alias this means MyType... should be 2. Although the alias this means MyType... Arredondo.
