Timon Gehr wrote:
> Ah, I see what you are getting at. I failed to read your post carefully enough. Sorry about that.

Hakuna matata ;)


> It is a parameterized scope that is analysed upon instantiation.

Yes, but my request is to have an un-parameter-atized syntax which is sugar for a template with zero parameters and is useful for sub-scoping objects. See below for a more detailed argument.


> This is an alternative:
>
> private template _unsafe(){
>     string name;
>     void bar() {
>         writeln(name);
>     }
> }
> struct Foo{
>     mixin _unsafe Unsafe;
> }
> 
> Is this better? (_unsafe can be a local template of struct Foo, but then it invades the allMembers)

Not really. Reasons is I actually want _unsafe to be part of allMembers, but I also want to use it in a syntactically appealing way. Also, by separating the template from the object, you're (conceptually) breaking OOP design, unless _unsafe is designed as a reusable packet of code (ie, used by more than just Foo, like UFCS), which isn't the goal I intended. Here's another example:

    class Fighter : Ship
    {
      template visual {
        VisualMesh mesh;

        void update() { /* use visual.mesh */ }
        void updateAfter() { /* ditto */ }
      }

      template physic {
        CollisionMesh mesh;

        void udpate() { /* use physic.mesh */ }
      }

      void update() {
        visual.mesh.doSomething();
        physic.mesh.doSomething();
      }
    }

Now we have three functions "update", and two fields "mesh", without any conflicts because they're separated by scope. The classic way to do this is simply to prefix the names: visualMesh, visualUpdate, physicMesh, etc... but scoping fits with OOP design, and allows each sub-scope to use each variable without prefixing, eg, "visual.update()" doesn't need to prefix "visual." when using "visual.mesh".

I know that this can be today, though alternative ways. However, this requires very little prior knowledge of D's idioms to understand. Meaning non-D programmers will understand this at a glance. It makes sense, and code is where it should be, saving us all a little bit of head-ache.


What may also be prudent, is to have parameterless mixin templates, something like:

    struct Person
    {
      mixin intros = template {
        void sayHi() { ... }
        void sayAge() { ... }
      }

      void sayHi() {
        intros.sayHi();
        intros.sayAge();
      }
    }

    void main() {
      auto philip = Person();

      philip.sayHi();
      philip.sayAge();
      philip.intros.sayHi();
    }

The problem with always using mixin templates is that sometime you want to require the scope prefix, like in the Ship example above.


> I think the current syntax hardly qualifies as unusable. I agree that it is not the prettiest/most specific one imaginable.

Agreed, though I don't see that as a reason to not *eventually* introduce a more usable syntax. If I had more time to dick around with DMD's internals, I'd make a pull request myself. I'm learning it, but it'll be awhile before I'll be trying to push code.


> Well, it can do it already.

Yes it can, but just even simple realiasing a template (or separating it out like your examples) requires a deeper understanding of D than what's graspable from my simple Ship example above. The easier to grasp, the more passing developer it will impress.


> D's design sacrifices ease of implementation to some extent.

I don't think it needs too, though. We could have both.

On Thursday, 19 April 2012 at 22:24:52 UTC, F i L wrote:
> snip

Sorry to dig this up again, but I'm looking for something to provide stubs for a compile time interface in a struct:

mixin template Stubs() {
    template __Stubs__() {
        void sayHi() { writeln("hi"); }
    }
    alias __Stubs__!() this;
}

struct Foo {
    mixin Stubs;
}

void main() {
    Foo().sayHi();
}

This is so that I am still able to override sayHi() at compile time with my own implementation in Foo.
I would love to do that, but it won't compile right now. If I alias to something else than this, it works though.
I could alias-this with an inner struct, i.e. when I change the template mixin to

mixin template Stubs() {
    struct __Stubs__ {
        void sayHi() { writeln("hi"); }
    }
    private __Stubs__ __s;
    alias __s this;
}

But this means I have to sacrifice some bytes in Foo to store the super struct, noticable as you add fields to Foo. This is not too bad, but since we have templates and mixins and stuff, is there maybe a way I haven't thought about?