typedef keyword?

[Andrej Mitrovic]

I recently had a good use for a typedef. I was interfacing with some C
code (explicitly loaded DLL), and I've made a function which allows me
to create wrapper functions for C automatically and add error checking
code which throws an exception, but only if the return value of a C
function is supossed to return an error code. The function would
return a list of these wrapped functions as a string, and then I would
mixin the string in a class.

For example, I could have thse C functions:

// C code
LIBError SomeFunction(void) { }
int anotherFunction(void) { }

and my function would create a dynamic loading mechanism for both
functions and add error checking for SomeFunction, the result would be
mixed in and a possible output would be:

// D pseudocode, loading mechanism and function pointer not shown here
void someFunction()
{
    auto result = CSomeFunction();

    if (result != LIBErrors.NoError)
    {
        throw new LIBException("SomeFunction returned failure code.", result);
    }

    return result;
}

int anotherFunction(void)
{
    return CAnotherFunction();
}

The function would only generate the exception code if the return
value of the C function is "LIBError". The problem with this is that
LIBError was defined as an alias for a uint (this was autogenerated by
htod from a C header file). So my function couldn't differentiate
between a C function returning an int vs returning a LIBError, because
an alias doesn't introduce a new type and I don't know of any
introspection mechanism for detecting types that are aliased or not.
So using the "typedef int LIBError" trick I was able to differentiate
between C functions that return an int vs a LIBError, and put my mixin
generator function to good use.

On 10/21/10, F.Almeida <francisco.m.almeida at gmail.com> wrote:
> Extensions to turn typedef into a more useful construct have already
> been proposed, but discussion on this has not evolved much since.
>
> My first, naive, idea was shown here:
> http://www.digitalmars.com/webnews/newsgroups.php?
> art_group=digitalmars.D&article_id=114489
>
> Both the syntax and the rules to enforce casting would need some
> work, but the basic idea is give the programmer control over which
> types such a variable can cast to and from.
>
> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>> In D.learn I have just given an answer about alias/typedef, in it
> I have said that the decision to deprecate typedef was in the end
> the right one:
>> http://www.digitalmars.com/webnews/newsgroups.php?
> art_group=digitalmars.D.learn&article_id=22387
>> But once some time is passed, what do you want to do with the
> typedef keyword? Just remove it and turn its usage in a syntax
> error? Keep in mind that the original purpose of typedefs in D was
> not imaginary, it was present to help a real need. If you program a
> little in Pascal/ObjectPascal/Ada you quickly learn that a typedef
> is useful.
>> So in my opinion a better solution is to design a better typedef,
> that uses the "typedef" keyword, and supports a more flexible
> semantics, as Andrei has suggested. This new usage of the "typedef"
> keyword may even be introduced in D3, there's no need to rush. The
> usage of "alias this" in structs will help, but a new usage of the
> typedef keyword may be syntax sugar for something else defined in
> Phobos. This new syntax of typedef may require a () after the
> keyword, to give space to specify the alternative kinds of typedef:
>> typedef(subtype) ... ...
>> The syntax typedef(...) is (I think) not syntactically compatible
> with C, so there is no problem with introducing a similar syntax
> with different semantics (this is even an improvement over D1, where
> typedef acts unlike C language).
>> Bye,
>> bearophile
>
>