Thread overview | ||||||
---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to luka8088 | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to luka8088 | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to luka8088 | 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: ------- |
Copyright © 1999-2021 by the D Language Foundation