Record and Tuple creation should be recursive. about proposal-record-tuple HOT 5 OPEN

I think this is a duplicate of #375

Applying the construction recursively could slow down creating the values, as the original mutable object would be created and then the 2nd record/tuple gets created. Having explicit syntax at the construction site makes this easier to avoid.

For an example like:

#{ p: [2,4] }

It looks like it is easy to optimise out the creation of the array and infer that the inner value should be a tuple but with indirection it becomes harder:

const getArr =  () => [2,4];
#{ p: getArr() };

More analysis is required to optimise out the array. This could lead to surprising performance differences between very similar code.

It may also result in errors, when invalid values are used; being thrown later due to the delay in converting the array/object to a tuple/record. Making it harder to spot the source of the invalid value.

from proposal-record-tuple.

Sure. But it will make the code reading more clear, which is always more important than how hard it is to write.

from proposal-record-tuple.

Why would there never be such a situation, where someone attempts or intends to do that?

from proposal-record-tuple.

I think that if recursive creation is not supported, it will not prevent people from trying to create nested Record/Tuple, but it will just make the code writing more cumbersome:

const getArr =  () => [2,4];
#{ p: #[...getArr()] };

from proposal-record-tuple.

Since it is deeply immutable, nested data must be converted to immutable. I don't think the more cumbersome way of writing it would make the code clearer to read.
Also I wish this syntactic sugar could be used for any expression, not just object/array literals.
I actually thought it would be more convenient to use # at the end of the expression:

const [head, ...rest] = [1,2,3]#
console.log(rest# === [2,3]#)

console.log(someObj.getSomeValue()# === targetTuple)

from proposal-record-tuple.