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


Reply via email to