Wasn't opDollar was fixed? Slices don't seem to be working... In one of my tests (can't duplicate here for some reason) using __dollar when it would see __dollar it complained about needing 'this' access.

struct S {
  int[] x;
  this(int[] x) {this.x = x;}
  int opDollar() {return x.length;}
  int __dollar() {return x.length;} //doesn't see this either
  int[] opSlice(int s, int e) {return x[s .. e];}
  int opIndex(int i) {return x[i];}
}

unittest {
  S s1 = [1,2,3];
  int last = s1[$ - 1];  //works
  int[] x = s1[0 .. $];  //needs __dollar??

  writeln(last); //never gets here, but should be 3
  writeln(x);    //never gets here, but should be [1,2,3]
}

 Oh yes, dmd version 2.60, Windows 32bit version. I pretty sure it would propagate all versions.

On Saturday, December 29, 2012 23:15:34 Era Scarecrow wrote:
>   Oh yes, dmd version 2.60, Windows 32bit version. I pretty sure
> it would propagate all versions.

That would be your problem. It's not fixed in 2.060. It was fixed since then. Use the latest from git or the current beta.

- Jonathan M Davis

On Saturday, 29 December 2012 at 23:58:49 UTC, Jonathan M Davis wrote:
> That would be your problem. It's not fixed in 2.060. It was fixed since then. Use the latest from git or the current beta.

 Hmm alright, I've installed the beta. New problems are creeping up curiously enough. There seems to be an invisibly added pointer 'this', which then makes a union break while using bitfields. This didn't break before...

 Unless I use the traits it doesn't show the problem. Any thoughts?

[code]
  static assert(__traits(compiles, {
    union xxx {
    int i;
    mixin("int geti() @safe const nothrow pure {return i;}void seti(int ii) @safe pure nothrow {i = ii;}");
    }
  }));
[/code]

output:

test.d(??): Error: static assert  (__traits(compiles,delegate pure nothrow @safe
 void()
{
union xxx
{
int i;
mixin("int geti() @safe const nothrow pure {return i;}void seti(int ii) @safe pu
re nothrow {i = ii;}");
void* this;
}
}
)) is false

On Sunday, December 30, 2012 04:33:54 Era Scarecrow wrote:
> On Saturday, 29 December 2012 at 23:58:49 UTC, Jonathan M Davis
> 
> wrote:
> > That would be your problem. It's not fixed in 2.060. It was fixed since then. Use the latest from git or the current beta.
> 
>   Hmm alright, I've installed the beta. New problems are creeping
> up curiously enough. There seems to be an invisibly added pointer
> 'this', which then makes a union break while using bitfields.
> This didn't break before...
> 
>   Unless I use the traits it doesn't show the problem. Any
> thoughts?

For any bugs that you find in the beta, bring them up in the beta list and create bug reports for them in bugzilla: http://d.puremagic.com/issues

Looking at the code though, I'm shocked to see a function declaration in a union. I wouldn't have thought that that was legal. But maybe that's why the static assertions are failing.

- Jonathan M Davis

On Sunday, 30 December 2012 at 03:43:09 UTC, Jonathan M Davis wrote:
> For any bugs that you find in the beta, bring them up in the beta list and create bug reports for them in bugzilla: http://d.puremagic.com/issues

 Will do


> Looking at the code though, I'm shocked to see a function declaration in a union. I wouldn't have thought that that was legal. But maybe that's why the static assertions are failing.

 Not my original idea; Actually it's part of a previous test case from std/format.d lines: 684-695. The original test case is actually to make sure that with no defaults that it doesn't try to set a default of throwing a 'overlapping initialization' error.

[quote]
  else
  {
    union
    {
      mixin(bitfields!(
            bool, "flDash", 1,
            bool, "flZero", 1,
            bool, "flSpace", 1,
            bool, "flPlus", 1,
            bool, "flHash", 1,
            ubyte, "", 3));
      ubyte allFlags;
    }
  }
[/quote]

On Sunday, 30 December 2012 at 03:43:09 UTC, Jonathan M Davis wrote:
> For any bugs that you find in the beta, bring them up in the beta list and create bug reports for them in bugzilla: http://d.puremagic.com/issues

 Couldn't find a previous mention of this case.

 http://d.puremagic.com/issues/show_bug.cgi?id=9244

On 12/30/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Looking at the code though, I'm shocked to see a function declaration in a union. I wouldn't have thought that that was legal.

It's legal in C++ and in D. I find it useful when interfacing with C++ non-POD types which have an embedded union, because it allows me to group related properties under a union declaration (it serves only as documentation), for example:

C++:
class Foo
{
public:
    Foo() { }

    union
    {
        int var1;
        bool var2;
    };
};

D:
///
class FooWrapper
{
    /// union property
    union
    {
        @property int var1();
        @property void var1(int i);

        @property bool var2();
        @property void var2(bool i);
    }
}