On Fri, 06 Apr 2012 10:56:19 -0400, Piotr Szturmaj <bncr...@jadamspam.pl>
wrote:
Steven Schveighoffer wrote:
On Fri, 06 Apr 2012 10:11:32 -0400, Manu <turkey...@gmail.com> wrote:
On 6 April 2012 16:56, Steven Schveighoffer <schvei...@yahoo.com>
wrote:
On Fri, 06 Apr 2012 09:53:59 -0400, Timon Gehr <timon.g...@gmx.ch>
wrote:
I think this proposal should be merged with Johannes' one.
It is very similar. I think the main distinction is that I focused on
the
fact that the compiler already has a mechanism to check and run CTFE
functions.
Except you're using a function, which I don't follow. How does that
work?
Where do you actually store the attribute data?
Just attaching any arbitrary thing, in particular, a struct (as in
Johannes
proposal) is far more useful. It also seems much simpler conceptually
to
me. It's nice when things are intuitive...
You can store a struct, just return it from an attribute function.
e.g.:
@attribute Author author(string name) { return Author(name);}
Compare it to:
struct Author { string name; }
@Author("John Doe") int x;
so now I must define a type for every attribute? I'd rather just define a
function.
What if I have 20 string attributes, I must define a new attribute type
for each one? This seems like unneeded bloat.
BTW, if I wasn't trying to demonstrate that you could store structs, I
would have written:
@attrubte string author(string name) { return name;}
and save the extra bloat associated with declaring another type. Maybe we
could even get this someday:
@attribute author(string name) => name;
I just don't see the need to declare a type that can wrap a string.
You could even add this rule:
if @attribute is placed on a struct, its constructor becomes an @attribute
qualified function with the name of the struct as the attribute name.
Why should we be restricted to only structs? Or any type for that
matter?
When using __traits(getAttributes, ...) you ask for conrete (struct)
type and you get it. In case of function you ask for serializable but
you get a bool.
It's an example. you can choose any type you want! I actually just want
the name of the author, I don't care whether that's a struct, or a string.
The benefit to using CTFE functions is that the compiler already knows
how to deal with them at compile-time. i.e. less work to make the
compiler implement this.
Compiler can easily deal with structs too:
I concede this is probably a non-issue.
I also firmly believe that determining what is allowed as attributes
should be opt-in. Just allowing any struct/class/function/etc. would
lead to bizarre declarations.
C# has requirement that attributes are classes that derive from base
Attribute class. But without that limitation you can do things like:
@Uuid("...")
interface MyIntf { }
without explicitly declaring Uuid as attribute. However, I don't see any
usage for primitive types:
@5
@"s"
@false
I don't understand what you are saying here.
I think that allowing values of structs, classes and _eventually_ enums
should be enough.
Any CTFE computed value should suffice.
-Steve
