BetterC Bug? Intended Behavior? Asking Here As Unsure

[Steven Schveighoffer]

On 7/7/20 8:26 AM, Steven Schveighoffer wrote:
> On 7/6/20 5:09 PM, kinke wrote:
>> On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
>>> Though, admittedly I'm kind of used to seeing this error message 
>>> since it appears any time you try and do something that relies on 
>>> type info in betterC, intentionally or not. A notable example is 
>>> forgetting to supply an arrange length when declaring a stack array, 
>>> or it'll try to create a runtime-allocated array.
>>
>> Similar case here; the 'varargs' end up in a GC-allocated array. I've 
>> recently changed `scope` slice params, so that array literal arguments 
>> are allocated on the caller's stack instead; so adding `scope` for 
>> these variadics *should* probably do the same:
>>
>> void tester(Test test, scope Test[] tests...);
> 
> Note that without the initial parameter, or without the destructor, they 
> do NOT end up on the heap.
> 
> I think this is a bug, and not a "feature". I can't see any reason why 
> in those two cases it can construct it on the stack, and in this case it 
> cannot.

I should clarify:
1. Removing the destructor, but leaving the initial parameter => stack 
allocated
2. Removing the initial parameter, but leaving the destructor => stack 
allocated

This is why I think it's at least inconsistent. A bug might be too far, 
since the spec clearly gives leeway to implementations to allocate on 
the heap.

But I would love to see the spec changed to require stack allocation.

-Steve