Re: bug in simplify_shallow

["Ruud H.G. van Tol" <rvtol@isolution.nl>]

On 2023-09-30 13:27, Bill Allombert wrote:
> On Sat, Sep 30, 2023 at 01:10:23PM +0200, Ruud H.G. van Tol wrote:
> > On 2023-09-29 23:05, Bill Allombert wrote:
> > > On Sun, Aug 27, 2023 at 05:01:07PM +0200, Ruud H.G. van Tol wrote:
> > > > On 2023-08-27 16:13, Karim Belabas wrote:
> > > > > [...] What Bill and I suggested was to return "a copy of the
> > > > > inserted element"
> > > > > instead. I don't really see a scenario where this would break
> > > > > compatibility ... except this would make insertion about twice slower,
> > > > > even in cases where the returned value is ignored.
> > > > Yes, so I wondered if the "void calling context" is decidable at
> > > > compile-time, such that any new overhead can be avoided where feasible.
> > > Indeed there used to be a bug in the compiler that I just fixed
> > > that caused it to fail to take the void context into account in
> > > some case.
> > Thanks for the changes and fixes!
> >
> > (also for not making it return the final length of the list ;) )
> Well, there still the issue that
>
> ? my(L=List());a=listput(L,5)
> ? a
> %2 = 0
>
> because GP convert void to 0...

And listpop() acts similar:

? my(L=List([42,43,44])); a=listpop(L); #L
%2 = 2
? a
%3 = 0


Maybe have an enabled compiler-error for such, to avoid surprises.

default(strictvoid, 1)


> > P.S. In paridecl.h, comparing listpop:
> >
> >   void    listpop(GEN L, long index);
> >
> > shouldn't these now also be void?
> >
> >   GEN     listinsert(GEN list, GEN object, long index);
> >   GEN     listput(GEN list, GEN object, long index);
> >
> > (or does GEN cover that already?)
> GP uses listinsert0 and listput0 which returns void.
> I have kept the return value for the C functions.

I presume that is good practice, to prevent breaking something at a 
distance.

-- Ruud