Do we want typedef support?

[bclothier]

Because I do lot of API declares, I've sometime wished that VB* would allow me to create typedefs -- having LongPtr represent HWND, HDC, and so forth can get quite tedious and make it possible to accidentally mix wrong kind of data that are otherwise compatible. If we allowed for capability to create a typedef statement, that would enable the compiler to provide a warning when a suspicious cast from one LongPtr to another LongPtr is going to be performed, which would go long way toward eliminating this class of programming errors. We can then specify explicit cast where it is appropriate which requires language support for this new class of type casting.

However, I'm on the fence over this one - the typedef statement is very Cish and not very BASICish. We have UDT but single-member UDT is quite awkward to use. This would be not very useful in a codebase that doesn't deal with API as much and thus would potentially be just a feature bloat.

It's also possible there are better way to solve this problem that doesn't involve adding even more lines of declarations to define the data types before the Declares.

Thoughts?

[WaynePhillipsEA]

I would be in favour of this. One of my goals with this project is to become the best possible COM / OLE Automation tool, and as such we should bear in mind that COM type libraries offer full support for typedefs ('aliases'), yet we currently have no way to create a type library that exposes an alias. Type library aliases are already supported in tB for consumption, and so this addition would be relatively simple to implement if we can agree a suitable syntax.

I'd be interested to hear others thoughts on this. Particularly from those that work with low-level Win API code often, which is where typedefs are often encountered.

[XusinboyBekchanov]

FreeBasic uses Type for this:
Type PControl As Control Ptr

[Kr00l]

I would suggest a shortcut version of a UDT declare.
Example
Public Type HWND As Long
So it can be Private or Public. The End Type is omitted and the datatype follows the type alias directly.

[wqweto]

Hiding pointers in typedef looks very powerful feature as well. Variables of PControl type above can be assigned LongPtr values say from VarPtr(MyUdt) but still dereferenced with members from Control e.g. pMyCtl.ControlMember1

This would make implementing WndProc and most other OS provided callbacks a breeze without CopyMemory and all the inefficient cruft VBx resorts to.

Such pointer types should be supported alias types in public typelibs though not sure.

[bclothier]

FWIW, I quite much like Kr00l's suggested syntax; feels like a natural extension of the existing Type statement. We still need to answer how the typecasting should be handled.

First, we need to recognize that in Windows it's very common to derive a type from another derived type. In Windows, the HWND is derived thus:

typedef void *PVOID;
typedef PVOID HANDLE;
typedef HANDLE HWND;

I am not sufficiently familiar with C/C++ to say whether that means the C/C++ compiler will allow downcasting of HWND into HANDLE, HANDLE into PVOID. If it does, then we need to allow for this with the proposed syntax:

Public Type PVOID As LongPtr
Public Type HANDLE As PVOID
Public Type HWND As HANDLE
Public Type HMENU As HANDLE

Given the syntax, this would be illegal:

Dim foo As HWND
Dim bar As HMENU

foo = bar 'Illegal, casting required

But this would be legal:

Dim foo As HWND
Dim bar As HANDLE

foo = bar 'Legal
bar = foo 'Not legal, casting required

We need to then consider what syntax for casting would be. In VB.NET they use DirectCast, TryCast and CType. All ugly, IMO. I think we should simply do something like this:

Dim foo As HANDLE 
Dim bar As HWND

bar = foo As HWND 'legal; casting is specified

In regards to @wqweto 's comment about callbacks --- I think that requires delegation support to properly handle the enforcement of procedure's signature when defining a callback procedure and may be a slightly different request. I love that idea, though as htat would make it very clear whether a procedure must be formatted a particular way.

[wqweto]

@bclothier VBx (COM actually) has already existing semantics for aliases (typedefs) and there so no (down) casting involved just regular conversion semantics for OLE Authomation types.

There are no new types outside oleauth introduced per se unless hidden pointers above are implemented. Great opportunity IMO with not much effort.

[bclothier]

@wqweto , correct. However, I was looking more from the C/C++ compiler's viewpoint -- it's my understanding (but I may be mistaken) that they enforce casting of the aliased types, so it's more than just merely an alias. If it's merely an alias, then there's not much benefit and increased cognitive load.

In Automation's case, if I'm reading the specs correctly, aliases are not supposed to be used in an Automation-compatible interface. We would probably see them in an non-Automation type library, though. I think that's why VB* has been able to get away with not supporting the aliases.

[wqweto]

Aliases are “resolved” to their basic types before any marshaling or other oleauth “activity” so there is no problem to assign 123 to OLE_COLOR as it’s just an alias for Long.

[WaynePhillipsEA]

I am not sufficiently familiar with C/C++ to say whether that means the C/C++ compiler will allow downcasting of HWND into HANDLE, HANDLE into PVOID. If it does, then we need to allow for this with the proposed syntax:

In C/C++, typedefs are treated exactly as if they are of the underlying type, and so in the example you gave, the values can be interchanged without any form of casting whatsoever. Therefore, my stance is that typedef support should be implemented exactly as it exists already in external type libraries, and LongPtr casting should be considered as a separate feature request, where the syntax can be discussed separately (...ideally with some Win API examples so that we can see and discuss the benefits more clearly).

[bclothier]

Thanks for the clarification. That said, I still would like to see compile-time checking of casting of typedefs (perhaps as a part of Option Strict) --- compile-time errors are much much cheaper to fix than runtime errors.

[WaynePhillipsEA]

Thanks for the clarification. That said, I still would like to see compile-time checking of casting of typedefs (perhaps as a part of Option Strict) --- compile-time errors are much much cheaper to fix than runtime errors.

That sounds like a good compromise to me.

[EduardoVB]

I would suggest a shortcut version of a UDT declare.
Example
Public Type HWND As Long

It sounds good, but I would suggest another option to consider:

Public Alias HWND As Long

[WaynePhillipsEA]

I would suggest a shortcut version of a UDT declare.
Example
Public Type HWND As Long

It sounds good, but I would suggest another option to consider:

Public Alias HWND As Long

I really like both versions! Let's put it to a vote...