grauzone Wrote:

> Robert Fraser wrote:
> > Jason House wrote:
> >> Andrei Alexandrescu Wrote:
> >>
> >>> Consider:
> >>>
> >>>      foreach (x; 1.0 .. 4.1) writeln(x);
> >>>      foreach_reverse (x; 1.0 .. 4.1) writeln(x);
> >>>
> >>> This sucks. foreach with interval for floating-point types should be disallowed.
> >>>
> >>>
> >>> Andrei
> >>
> >> I agree that makes little sense.
> >>
> >> I'm curious, why the sudden pruning of features? Can you please consider removing SFINAE? I'd also love to see is expressions go the way of the dinosaur. I don't know what their replacement should look like, but there _has_ to be a better and less error prone syntax!
> > 
> > I agree about SFINAE, but what's so bad about is()? If it does get removed, I hope whatever replaces it can do all the weird things is can (e.x. is(typeof({}())))
> 
> Isn't is() also a kind of SFINAE? SFINAE is Substitution Failure Is Not An Error (or so). That means, if there's an error trying to apply  a template, the error is silently ignored, and the compiler tries the next template declaration. (Correct me if I'm wrong.) is() does something similar: it tries to compile the expression inside is(), and if it fails, the compiler silently ignores the error and returns "false" to the if.
> 
> The problem is: you can't really know if that what you intended to test with is() was false, or if another random semantic error happened inside the is() expression.
> 
> Look at this for example:
>  > writefln("%s", is(typeof(rtzx) == char));
> This compiles even if rtzx doesn't exist. But you probably wanted to
> check the type of rtzx, not it if rtzx exists. If you mistyped rtzx, the
> compiler will never tell you.
> 
> Now Andrei didn't really explain his problem with is()...

Andrei didn't voice a complaint about is expressions. I did. If you take a look at the documentation on them, you'll see 8 different flavors. Can you honestly reproduce that list without looking it up? Here's a hint: is(typeof(...)) isn't listed in the docs. Here's a simpler question: how do you test for an associative array of string types indexes by a numerical type while exposing a type alias for the index type?

Here's a recent misuse by Andrei that made its way into Phobos:
if (is(T == struct) && is(T.toString))

Jason House:
>how do you test for an associative array of string types indexes by a numerical type while exposing a type alias for the index type?<

When I use my dlibs in D1 to solve a problem like that I use:

static if (IsAA!(T1) && IsNumeric!(KeyType!(T1))) {
    alias KeyType!(T1) Tkey;
    ...
}

Easy and not not much error prone. I have had no need to look into the docs.

Bye,
bearophile

On Mon, May 18, 2009 at 5:46 AM, Jason House <jason.james.house@gmail.com> wrote:

> Here's a recent misuse by Andrei that made its way into Phobos:
> if (is(T == struct) && is(T.toString))

Hmm, 'is' isn't supposed to accept values is it?  But it quietly ignores anything wrong and returns false.  Is that the misuse you're talking about?

--bb