TwinBasic

[Niya]

Nonsense.

What I want (doing compiler-development myself), is the developer to concentrate on 1:1 compatibilit first.
That's "hard enough" to do.

That's fair as long as it doesn't just stop there at 1:1 compatibility. That's all I'm saying.

And in case of Tuple-support, we basically already have "full compatibility, to how python handles tuples".
in python, you write:
SomeTuple = (1, 2, 3)
and you access "tuple-members" by specifying a zerobased index:
print(SomeTuple[0])

In VB we would do:
SomeTuple = Array(1, 2, 3)
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

So, one simple thing a compiler-dev could do (if the goal is, to make it "more python-compatible") -
is, to make the Array-Function specifier "optional" (which should not be that hard, when a comma-separated list is enclosed by parentheses).
So, that the "new VB" code could be written this way:
SomeTuple = (1, 2, 3) ' or Return (1, 2, 3) which TB already supports for function-results
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

Eh voila, python-compatible tuple-support in "new VB"...

Well I'll say this. For me personally, Tuples aren't something I'll fight to the death for but that doesn't mean others won't. I could personally live without them but I do see their value and I can understand why some may want them. All I'm saying is to give these people a fair hearing.

As for the kind of new features I would like to see (or implement) in a VB6-successor,
I would always prefer to open it up to the "lower end" - so that it becomes more "C-like".

E.g. an easy way to pre-define Function-Declarations in a Const-Variable -
then passing this "typed Function-Pointer" along into Routines (as a nice, lowlevel way to support "delegates").

VB6 already is as a thin (COM-layer-supporting) abstraction on top of C/C++...
And I would like (in potential new features), when it would "open up a bit more to that lower level" -
(making it easier to access with less typing-efforts, supported by more compiler-checks).

Olaf

This I definitely agree with. Towards this I've always held the opinion that TwinBASIC could be spiced up with strong control over marshalling like we have in .Net where we can control how certain data types are marshalled to and from the Win32 API and other external binaries.

Another thing I think would be valuable is more access to COM internals specifically with regards to the generation of type libraries. Basically an easy mode MIDL type thing where you can opt for direct control over what is written type libraries when you compile something like an ActiveX DLL. I can't remember specifics today but way back in the day I remember being frustrated by the lack of control over COM from within the VB6 environment.

EDIT:

I just remembered one. I wanted the ability to specify my own interface IDs for COM interfaces in an ActiveX DLL. I don't remember why I wanted this but I do remember not being able to do this from VB6. This was very long ago mind you so my memory is a bit rusty.