On 5/17/16 1:49 PM, Rory McGuire via Digitalmars-d-announce wrote:
On 17 May 2016 16:21, "Steven Schveighoffer via Digitalmars-d-announce"
<digitalmars-d-announce@puremagic.com
<mailto:digitalmars-d-announce@puremagic.com>> wrote:
>
> On 5/17/16 10:06 AM, Jack Stouffer wrote:
>>
>> http://jackstouffer.com/blog/d_auto_decoding_and_you.html
>>
>> Based on the recent thread in General, I wrote this blog post that's
>> designed to be part beginner tutorial, part objective record of the
>> debate over it, and finally my opinions on the matter.
>>
>> When I first learned about auto-decoding, I was kinda miffed that there
>> wasn't anything in the docs or on the website that went into more
>> detail. So I wrote this in order to introduce people who are getting
>> into D to the concept, it's benefits, and downsides. When people are
>> confused in Learn why typeof(s.front) == dchar then this can just be
>> linked to them.
>>
>> If you think there should be any more information included in the
>> article, please let me know so I can add it.
>
>
> Starting to read it, see errors in your examples:
>
> is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char))
> is(s.front == dchar) -> is(typeof(s.front()) == dchar)
>
> I'm not sure if you need the parens after front, but if it's not
marked as @property, then this returns a function.
>
If I remember correctly adding the brackets then goes against best
practices because you can't be sure the underlying implementation of a
range is using a function for .front.
Right, but there's this:
struct MyRange
{
private int _val;
int front() { return _val; }
bool empty() { return _val < 100; }
void popFront() { ++_val; }
}
static assert(isInputRange!MyRange);
static assert(!is(typeof(MyRange.init.front) == int));
This is why I recommended the parentheses. In reality, you should do
ElementType!MyRange, which does the correct thing. But is(typeof(...))
doesn't always work like you might expect.
-Steve
