View mode: basic / threaded / horizontal-split · Log in · Help
October 08, 2012
[Issue 8785] New: feature request: static mixin
http://d.puremagic.com/issues/show_bug.cgi?id=8785

          Summary: feature request: static mixin
          Product: D
          Version: D2
         Platform: All
       OS/Version: All
           Status: NEW
         Severity: normal
         Priority: P2
        Component: DMD
       AssignedTo: nobody@puremagic.com
       ReportedBy: luka8088@owave.net


--- Comment #0 from luka8088 <luka8088@owave.net> 2012-10-08 12:43:25 PDT ---
Currently, there is no way of encapsulating mixin templates as static keyword
has no effect.

import std.stdio;

mixin template myTemplate () {
 void fn () {
   writeln("myTemplate");
 }
}

struct myStruct {
 static mixin myTemplate t1; // static keyword has no effect
}

void main () {
 myStruct s1;
 s1.t1.fn(); // myTemplate
 s1.fn(); // myTemplate
}

I would kindly request that static keyword encapsulates the template members so
that s1.fn is not directly accessible but rather only as s1.t1.fn

One hack proposal was to use

static struct t1 {
 mixin myTemplate;
}

but that turned out to be a bed idea because in that case mixin code can't use
this to access myStruct

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 26, 2013
[Issue 8785] feature request: static mixin
http://d.puremagic.com/issues/show_bug.cgi?id=8785


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
                CC|                            |andrej.mitrovich@gmail.com


--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-26 15:16:21 PST ---
What this would basically do is introduce namespaces into the language, as 't1'
would be some kind of pseudo-type which has access to its parent, but it itself
wouldn't be a template (since it doesn't require !()), and it wouldn't be an
aggregate.

Not that there's anything wrong with that. :)

Anyway for the longest time I actually thought "mixin myTemplate t1" means the
symbols are only accessible through "t1", but the spec does say it's only used
for disambiguating so I was wrong.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 26, 2013
[Issue 8785] feature request: static mixin
http://d.puremagic.com/issues/show_bug.cgi?id=8785


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
          Severity|normal                      |enhancement


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 27, 2013
[Issue 8785] feature request: static mixin
http://d.puremagic.com/issues/show_bug.cgi?id=8785



--- Comment #2 from luka8088 <luka8088@owave.net> 2013-01-27 12:21:19 PST ---
(In reply to comment #1)
> What this would basically do is introduce namespaces into the language, as 't1'
> would be some kind of pseudo-type which has access to its parent, but it itself
> wouldn't be a template (since it doesn't require !()), and it wouldn't be an
> aggregate.
> 
> Not that there's anything wrong with that. :)
> 
> Anyway for the longest time I actually thought "mixin myTemplate t1" means the
> symbols are only accessible through "t1", but the spec does say it's only used
> for disambiguating so I was wrong.

I also thought this way, until I read the docs properly. It would be useful in
some cases to have both behaviors. "static" is proposed because it is already
used with imports in this way - "import" vs "static import". Maybe "static" is
not the best keyword/solution for this case but it is the first solution that
came to mind.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Top | Discussion index | About this forum | D home