here is some code for your amusement:

struct Input {
  auto opSlice (size_t start, size_t end) {
    static struct InputSlice {
      @property bool empty () { return false; }
      @property char front () { return 0; }
      void popFront () {}
      InputSlice save () { return this; }
    }
    import std.range.primitives;
    static assert(isForwardRange!InputSlice);
    return InputSlice();
  }
}

fixing code like this tames `isForwardRange`:

template isForwardRange(R)
{
    enum bool isForwardRange = isInputRange!R && is(typeof(
    (inout int = 0)
    {
        R r1 = R.init;
        //old: static assert (is(typeof(r1.save) == R));
        auto s1 = r1.save;
        static assert (is(typeof(s1) == R));
    }));
}

i wonder if some other checking primitives has similar bug.

On Mon, 04 May 2015 10:25:23 +0000, ketmar wrote:

https://issues.dlang.org/show_bug.cgi?id=14544

On Monday, 4 May 2015 at 10:25:23 UTC, ketmar wrote:
> here is some code for your amusement:
>
> struct Input {
>   auto opSlice (size_t start, size_t end) {
>     static struct InputSlice {
>       @property bool empty () { return false; }
>       @property char front () { return 0; }
>       void popFront () {}
>       InputSlice save () { return this; }
>     }
>     import std.range.primitives;
>     static assert(isForwardRange!InputSlice);
>     return InputSlice();
>   }
> }
>
> fixing code like this tames `isForwardRange`:
>
> template isForwardRange(R)
> {
>     enum bool isForwardRange = isInputRange!R && is(typeof(
>     (inout int = 0)
>     {
>         R r1 = R.init;
>         //old: static assert (is(typeof(r1.save) == R));
>         auto s1 = r1.save;
>         static assert (is(typeof(s1) == R));
>     }));
> }
>
> i wonder if some other checking primitives has similar bug.

Add @property to save.

On Mon, 04 May 2015 14:33:11 +0000, Alex Parrill wrote:

> Add @property to save.

another arcane knowledge. i'm seriously thinking about going back to C++, as i know that C++ is insane and full of such warts. and with C++ i have full access to all C and C++ libraries.

consistency issues tend to be ignored in D, dunno why. C++ become popular not due to it's weirdness, and make D weird and unintuitive will not automatically made it popular. i'd say the opposite.

"isForwardRange	Tests if something is a forward range, defined to be an
input range with the additional capability that one can save one's
current position with the save primitive..."

ok, i have "save primitive" here. it's not working. yet it's not a bug, ok. just another meaningless limitation that has no useful purpose.

On Monday, 4 May 2015 at 15:08:04 UTC, ketmar wrote:
> consistency issues tend to be ignored in D, dunno why. C++ become popular
> not due to it's weirdness, and make D weird and unintuitive will not
> automatically made it popular. i'd say the opposite.

It is a much lesser problem that Phobos is weird than the language, libraries are easy to fix. But yes, I can't think of a single non-framework language that has shown growth over a long period of time without making aesthetics a selling point: Lisp, Haskell, Ruby, Python… Obviously if people are dealing with ugly on the job, they want something clean when they get to pick and choose.

Out of curiosity, did you give up on Aliced now that dmd is moving to D from C++?

On Tue, 05 May 2015 18:28:11 +0000, Ola Fosheim Grøstad wrote:

> Out of curiosity, did you give up on Aliced now that dmd is moving to D from C++?

in no way. actually, i'm waiting for "final move" (i.e. for dropping C++) to implement some features i want to have.

Aliced is fully backwards compatible with "vanilla" (sometimes it needs cli switches for that, but i'm fixing that; it should be enough to declare module as `module mymod is aliced;`), and i'm not changing Phobos in a destructive way (i prefer to copypaste code under another name if i need destructive changes).

so i will have no problems with upcoming frontend transition. quite the contrary, it will open some possibilities for me. i'm seriously thinking about AST macro engine, backed by metaprogramming to generate boilerplate code, for example.

On Thursday, 7 May 2015 at 15:12:04 UTC, ketmar wrote:
> so i will have no problems with upcoming frontend transition. quite the
> contrary, it will open some possibilities for me. i'm seriously thinking
> about AST macro engine, backed by metaprogramming to generate boilerplate
> code, for example.

Thanks for sharing. :-) It is interesting and fun to read about how people take the compiler/language in new directions.

You probably would like to look at the language Pure before digging deep into AST macros. It is based on term rewriting.

On Thu, 07 May 2015 16:02:35 +0000, Ola Fosheim Grøstad wrote:

> You probably would like to look at the language Pure before digging deep into AST macros. It is based on term rewriting.

thank you, i'll take a look at it. i remember that i met that name before.