Would an Assign operator be useful

[FullValueRider]

In VBA we have the awkward boilerplate of

   If VBA.IsObject(myFoo) then
       Set myBar = myFoo
   Else
       myBar=myFoo
   End If

twinBasic has made great strides by eliminating this construct by
• Introduction of Generics
• the return statement

Other authors use the various variant copy methods

Given all of the above I'm wondering if there any possibility of eliminating the above boilerplate by introducing a new method or operator.
e.g. as Operator

    myBar <- myFoo

or as Method

   Assign myBar = myFoo

[bclothier]

Note: moved this to lang-design since this is about language syntax.

IMO, I think a far more natural solution would be to get rid of the artificial distinction between Let and Set. The only reason it even exists is because of how they implemented the default member access, which I think is actually more harmful than helpful. As I've written before, many people trip up on this:

Dim con As ADODB.Connection
Dim cmd As ADODB.Command

Set con = New ADODB.Connection
con.Open ....

Set cmd = New ADODB.Command
cmd.ActiveConnection = con

This is legal but it doesn't do what one might expect due to the implicit default member access. Because it is legal, it also is hard to see that it's wrong.

I feel that a new syntax would only compound problems. If we're going to change anything, IMO, that should involve taking away rather than adding to.

[FullValueRider]

I can see where you are coming from but I think that its the totally wrong perspective for twinBasic. Removing the option to have default members would break a lot of VBA code. I use it extensively for the Item method, or if I don't have an item method, the factory constructor to avoid having to 'New' things.

With the Operator/Method proposal, its introduction doesn't change how existing code works. BUT is is just a quality of life thing.

If I wanted to to quote an analogy it would that that adding one more wart to a warty thing doesn't resolve the wartiness, but at least the Warts now have a more aesthetic pattern.

[bclothier]

For the record I agree that removing would create more problem and wasn't serious about it.

Still, there's a reason why "do no harm" is the first thing on the hippo oath. :)

[mburns08109]

@FullValueRider

I'm kind of torn on this suggestion.

While I can appreciate syntactic sugar as much as the next sweetness addict, I'd be concerned that those pesky Beginners I'm always harping about might get more confused (at least visually) between your proposed "<-" operator and the pre-existing "<=" logical comparison operator.

I'd think that the statement form would be "more 'basic-y'" (wow, talk about a new construct in languages, there's one).
...but I just question the value of it -vs- the (unseen as yet) risk-of-it / effort-to-implement of it. (perhaps there'd be some hidden complexity when dealing with COM interfaces or some such thing?)

After all, we've been seeing that original construct pattern literally forever in VBx to date, and other than being a tad tiresome to read over and over, what's the harm? (and then there's Ben's/XKCD's point to consider.)

[rexxitall]

I found the Pascal thing optically and logically nice :) var.^

[FullValueRider]

I put the suggestion forward because I've been using the following

Public Sub Assign(ByRef opTo As Variant, ByRef ipFrom As Variant)
    If IsObject(ipFrom) Then
        Set opTo = ipFrom     
    Else
        opTo = ipFrom
    End If
End Sub

Which seems to work most of the time. However I must be missing something because it doesn't work ALL the time.

If we followed the Mantra of 'forever in VBx to date,' we wouldn't have the new return statement, nor the AndAlso and OrElse, the new if statement etc etc etc.

So, given that I can almost achieve what I want in Standard VBA I thought it would be a reasonable idea to put forward. The fact that this hasn't already been implemented by Wayne makes me think there may be snags in the background I'm not aware of.

So, it may be a small thing, but lots of small things makes a big difference.

[mansellan]

There's exactly the same problem with generics. It would be tiresome to have to check IsObject everywhere you wanted to assign a generic type parameter too.

[wqweto]

Set varA = varB would raise runtime error if varB is not a reference. Does any code depend on such runtime error? Why not silently succeed?

Another option would be inteoduce a new keyword Let, Set so Wet probably or overload an existing obscure keyword like LSet working now for Variants (instead of UDTs only)

[mansellan]

"Does any code..." no way to know, and changing that would break the 100% goal.

I think Assign is the most self-explanatory choice for a keyword.

EDIT: maybe Set silently succeeding could work, if that behaviour was optional in the project settings.

[wqweto]

Of course I could suggest using Array(varA) = Array(varB) work-around if destructuring assignment is ever implemented :)) This could be optimized away by the compiler so no intermediary array is created too.