Quote Originally Posted by fafalone View Post
I don't see how there's any 'opt in' or separation at all when I can't even remember the last time I saw a non-trivial VB program that wasn't calling into APIs. The the purest sense you'd still be opting in, in the sense that nothing is making you use any enhanced pointer functionality, and the language supports ways to avoid it for all the most common situations. We could consider taking the VB6 road of "This is undocumented and unsupported"... like I don't know how official the current situation is with being able to substitute LongPtr for a UDT or As Any.

Public Sub Foo(p As Bar) can be called with Dim ptr As LongPtr: Foo ptr

You make fine points but none of them address the reality that there is no avoiding raw pointers in VBx/tB, for any program of meaningful complexity. Are we saved from buffer overruns and accessing invalid pointers by requiring CopyMemory and manual pointer math? No, in fact I think we open up a *larger* attack surface. Unless there's a world where the use of pointers isn't needed (or at least, only rarely needed), making them friendlier is the only option.

.NET can get away with those restrictions because of the massive, massive frameworks that dramatically limit the need as they wrap nearly the entire API surface. But that's not the road tB is taking, nor the road I'd want it to take. There's a reason so many of us haven't abandoned VB6 for .NET. So given that pointer use will remain pervasive, it's better to have first class support.
I think yourself and Niya are approaching this from different viewpoints.... If you are used to VB6 then having to use APIs to overcome a lot of the limitations is completely normal, plus the language makes it hard to pass things to the APIs as well. CopyMemory, GetMem, PutMem, etc. are required to do a lot of things. I suspect Niya is approaching this from a C# / VB.Net point of view - the language provides easier ways of calling APIs that doesn't require your code to be full of pointers (or in the case of https://learn.microsoft.com/en-us/do...rce-generation this low level code is generated for you).

I think if you are constantly having to use raw memory access and pointers in a a high level language like Basic then something is wrong - either the language is not sufficiently high level enough, or you are using the wrong language for the job. I am willing to admit there will be occasions raw memory access is needed, but these shouldn't be the common case in a high level language. Ideally the environment should take care of as much of this as possible.