Allow property get vs. set to be of different types

[Zlatkovsky]

Currently, TypeScript requires that the get and the set types of properties match. However, there are scenarios where, I think, it would be very useful to have a set that is more accepting than the get.

For example: imagine you have a property of Array<Array<string>> type. Today, this means that both the get and set would have to be of the same type, and so setting the property would always be done via the array notation.

It seems reasonable, however, to allow the "setter" to be more forgiving and let it coalesce a single string value into an array automatically. That way, when setting the property, you could either do cell.values = [[1]] or just cell.values = 1, and the class would accept either syntax. But for return values, it would always return an array type, and so the get of the values property should still be marked as Array<Array<string>> (that way you would get all the good IntelliSense of having .filter, .forEach, etc., on the return type).

class Cell {
    private _values: Array<Array<string>>;
    get values():Array<Array<string>>{
        return this._values;
    }
    set values(values: Array<Array<string>>|string) {
        if (values instanceof Array) {
            this._values = <Array<Array<string>>>values;
        } else {
            this._values = [[<string>values]];
        }
    }
}

Today, this code would trigger an error that "get and set accessors must have the same type".


The only workarounds available today are both less than ideal:

1. Set the property of values -- both "set" and "get" -- to any. But in doing so, you lose all IntelliSense.

2. Mark the property -- both "set" and "get" -- as Array<Array<string>>|string. However, while this solves the "set" problem, the "get" property loses a lot of the IntelliSense (.filter, .forEach), and is actually no longer true to reality (the return value is always an array, not an "array or a string")

Would be great if the scenario of a "more inclusive set property" could be supported.

[RyanCavanaugh]

Duplicate of #2521