On Monday, 26 November 2012 at 16:32:17 UTC, Manu wrote:
> And fail! functionAttributes breaks when I pass basically anything that's
> not a function >_<

Answer quick: What would the function attributes be of something that isn't a function?

David

On 26 November 2012 20:27, David Nadlinger <see@klickverbot.at> wrote:

> On Monday, 26 November 2012 at 16:32:17 UTC, Manu wrote:
>
>> And fail! functionAttributes breaks when I pass basically anything that's not a function >_<
>>
>
> Answer quick: What would the function attributes be of something that isn't a function?


No attributes I guess.
If it's the only way to test if something is a property, then it needs to
be able to accept anything I give to it that may or may not be a property.

On 11/27/2012 1:36 AM, jerro wrote:
>> That doesn't work, immutable breaks that test.
>
> You're right. I didn't expect that. It seems that this compiles:
>
> void foo()
> {
>      immutable a = 1;
>      enum b = a;
> }
>
> But this doesn't, obviously:
>
> void foo(immutable int a)
> {
>      enum b = a;
> }
>
> I wonder, is this considered a bug? It seems very inconsistent to me.

It's not a bug. In  the latter case, b is a manifest constant, and its value cannot be determined at compile time. Hence, it will not compile.

On 11/27/2012 2:04 AM, Timon Gehr wrote:
> Because 'const' already denotes 'readonly'. :o)

const also implies it's an lvalue. A manifest constant cannot be an lvalue. This has some subtle implications with, for example, declaring const or enum members of a struct.

On 11/27/2012 4:30 AM, Manu wrote:
> Here's what I have, and it's not even close to working:

Actually, that is a pretty nice list, and we should get them all working with template traits that are reliable and properly supported.

On 26 November 2012 23:25, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/27/2012 4:30 AM, Manu wrote:
>
>> Here's what I have, and it's not even close to working:
>>
>
> Actually, that is a pretty nice list, and we should get them all working with template traits that are reliable and properly supported.
>

I don't think I have words to express how awesome that would be! :)

On 11/27/2012 4:30 AM, Manu wrote:
>     template isEnum(alias T) if(is(T)) {

It isn't clear what is desired here. Given:

enum E { A, B }

E is the enum tag name, which is quite different from the enum members A and B. And, the enum tag name is indistinguishable from the enum type. Furthermore, an enum member is indistinguishable from an enum value. So, I suggest instead:

   isEnumType

and:

   isEnumValue

On 27 November 2012 03:56, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/27/2012 4:30 AM, Manu wrote:
>
>>     template isEnum(alias T) if(is(T)) {
>>
>
> It isn't clear what is desired here. Given:
>
> enum E { A, B }
>
> E is the enum tag name, which is quite different from the enum members A and B. And, the enum tag name is indistinguishable from the enum type. Furthermore, an enum member is indistinguishable from an enum value. So, I suggest instead:
>
>    isEnumType
>
> and:
>
>    isEnumValue
>

I accept. They seem like good names.

There's another you missed:
enum X = 10;
I would have imagined this would be semantically identical to E.A/E.B, but
the compiler seemed to view this as distinct in my experiments.

On 11/27/2012 9:51 PM, Manu wrote:
> There's another you missed:
> enum X = 10;
> I would have imagined this would be semantically identical to E.A/E.B,
> but the compiler seemed to view this as distinct in my experiments.

Those are not enums, they are manifest constants. What distinguishes a manifest constant from, say:

    const Y = 11;

is that no storage is allocated for X, and X's address cannot be taken.

On Tuesday, 27 November 2012 at 21:16:41 UTC, Walter Bright wrote:
> On 11/27/2012 9:51 PM, Manu wrote:
>> There's another you missed:
>> enum X = 10;
>> I would have imagined this would be semantically identical to E.A/E.B,
>> but the compiler seemed to view this as distinct in my experiments.
>
> Those are not enums, they are manifest constants. What distinguishes a manifest constant from, say:
>
>     const Y = 11;
>
> is that no storage is allocated for X, and X's address cannot be taken.

What distinguishes manifest constants from literals? Aren't manifest constants just literal aliases? That is, if the following did work

alias Y = 11;

wouldn't that be exactly same as

enum Y = 11;

Perhaps using "alias" instead of "enum" would make the meaning clearer?