October 27, 2004
Regan Heath:
> I have mentioned this before, but I kinda want some more opinions on the matter/idea.
> 
> Currently we have to specify an enum by it's full name, this can be quite long and you can end up writing/copying/pasting the enum name a few times.
> 
> Surely it's possible in most cases for the compiler to determine the Enum name and thus it's not really required.

I don't know if there was any kind of conclusion since I skimmed this thread pretty quickly (several months of catching up to do), but is this a possibility:

enum FooBarBaz : ushort
{
    THE = 0x0001,
    QUICK = 0x0002,
    BROWN = 0x0004,
    /* and what have you */
}

void fooBar(FooBarBaz a)
{
    {
        FooBarBaz x = THE;  // error - THE not in scope
        FooBarBaz y = FooBarBaz.THE // ok
    }
    {
        import FooBarBaz;   // bring names in FooBarBaz in current scope
        FooBarBaz x = THE;
    }
}

As this has a direct analogy in importing modules, there is
no new semantic baggage. And no need to complicate lookup rules,
I believe.

-Antti

October 28, 2004
Antti Sykäri wrote:

> I don't know if there was any kind of conclusion since I
> skimmed this thread pretty quickly (several months of
> catching up to do), but is this a possibility:
> 
> enum FooBarBaz : ushort
> {
>     THE = 0x0001,
>     QUICK = 0x0002,
>     BROWN = 0x0004,
>     /* and what have you */
> }
> 
> void fooBar(FooBarBaz a)
> {
>     {
>         FooBarBaz x = THE;  // error - THE not in scope
>         FooBarBaz y = FooBarBaz.THE // ok
>     }
>     {
>         import FooBarBaz;   // bring names in FooBarBaz in current scope
>         FooBarBaz x = THE;
>     }
> }
> 
> As this has a direct analogy in importing modules, there is
> no new semantic baggage. And no need to complicate lookup rules,
> I believe.

Here's the current dirty workaround that I resorted to:

//enum FooBarBaz : ushort
alias ushort FooBarBaz;
enum
{
    THE = 0x0001,
    QUICK = 0x0002,
    BROWN = 0x0004,
    /* and what have you */
}

Not type-safe, but "better" than porting all that C...


Some kind of import, like you suggest above, would be
a nice feature and minimize typing, and similar hacks.

Having to type the enum each time is about as tedious
as typing the full module name for each function call.

And "import" is a handy solution for that already, so...
(and with the "alias" to resolve any naming collision)

I couldn't find it in the FeatureRequestList, though ?

--anders
October 28, 2004
In article <clqc7n$1lf8$1@digitaldaemon.com>, Anders F Björklund wrote:
> Antti Sykäri wrote:
[my suggestion to pull names out of enums with import]
> 
> Here's the current dirty workaround that I resorted to:
[...]
> 
> Not type-safe, but "better" than porting all that C...
>
> Some kind of import, like you suggest above, would be
> a nice feature and minimize typing, and similar hacks.

Yes.

Better type-safe than sorry, right?. IMO language should not punish you for wanting type safety.

"import" could be extended to other things than just enums - actually everything that contain a namespace. While it would be most useful with enums, occasionally I'd like to "import" some static members of classes/interfaces/structs and template instances as well.

> I couldn't find it in the FeatureRequestList, though ?

So there was a list like that. Here's the URL to those that haven't found it yet:

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Actually I went to wiki4d in the first place but couldn't find a link to anything like that, so I gave up.

Back to the "import for enums,  than modules":
Perhaps I, or someone else, will need to write an entry in that list.

Is there any interest for a feature like this?

-Antti
1 2 3 4 5
Next ›   Last »