> Hi @vdubya, this is a known issue that we expect to fix for next release: basically our grammar (more precisely the parser ANTLR generates with it) has a problem with an array call that's made out of the result of a function.

In other words, this works around the issue:

Sub test()
Dim ws1, ws2 As Worksheet
Set ws1 = Worksheets(1)
Set ws2 = Worksheets(2)
Dim rng As Range
Set rng = ws1.Range("namedrange")
rng(2) = ws2.Range("A1")

> Rubberduck.Setup.1.4.3.0.exe(4.32MB) - Downloaded 503 times.
Last updated on 2015-07-08

> The COM-visible `Rubberduck.AssertClass` is implementing `AreEqual` in a type-safe way that is *expected* in .net but that can be surprising in VBA:

if (expected.GetType() != actual.GetType())
{
AssertHandler.OnAssertInconclusive("[expected] and [actual] values are not the same type.");
return;
}

Let's implement and expose a `PermissiveAssertClass` that implements equality checks in a more VBA-like way - this involve

> Nothing else needs to change anywhere; the VBA code is responsible for creating the `AssertClass` instance, and the test engine listens for `public static event EventHandler<AssertCompletedEventArgs> OnAssertCompleted` in the `AssertHandler` static class, so the `PermissiveAssertClass` could look like this (assuming `AssertClass` members are made `virtual`):

[ComVisible(true)]
[ComDefaultInterface(typeof(IAssert))]
[Guid(ClassId)]
[ProgId(ProgId)]
public class Permis

> I find it counterintuitive to decide how exact my Asserts are by a configurable setting. I'd sure prefer one statement to always mean the same across all projects. Instead I'd personally move these "loose" asserts into differently named methods / a different class.

This may allow you to still configure which of these two you prefer, but `AssertEquals(a, b, "wat")` should for the same a and b always return the same result.

> @Vogel612 fair point; the problem is that VBA and C#'s respective definition of "same a and b" are different, because VBA is quite generous with implicit conversions.

The current `AssertClass` behaves more like C# and, while it's good to be strict with types, a VBA programmer may prefer, or *expect* (or *need*?) "123" to be considered equal to 123. Or more subtly, 123 (`Integer`) to be equal to 123 (`Byte`) or 123 (`Long`).

I'd keep the current implementation the default, but allow the u

> @Vogel612 just picked up "or move them to a different class" - that's exactly what I'm suggesting: by default, adding a new test module would create a new standard module featuring this line:

Private Assert As New Rubberduck.AssertClass

What this issue is suggesting, is to give the ability to do this:

Private Assert As New Rubberduck.PermissiveAssertClass

The configurable part merely determines which class is being instantiated by default - user can switch one for the other