<div dir="ltr"><div>I would suggest that we should only commit to stable branches for the purpose of fixing a bug. No, we don't promise a stable API, so it may arise that we need/want to change the API in a micro release to accomodate a bugfix, though we still should try to avoid it (and generally have, I think.)</div><div><br></div><div>Changing the API in a stable branch because our aesthetics have changed, or because it might make it easier to backport a hypothetical bugfix, seems like a bad idea. If I were an external user of these typedefs (</div><div><a href="https://github.com/search?q=geom%3A%3AGeometry%3A%3APtr+NOT+is%3Afork&type=code&p=1">https://github.com/search?q=geom%3A%3AGeometry%3A%3APtr+NOT+is%3Afork&type=code&p=1</a>), or a packager of software that uses them, I would be upset that upgrading from 3.12.2 to 3.12.3 caused them to disappear.</div><div><br></div><div>Dan<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2025 at 6:33 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">There seems to be agreement that purging pointer aliases is A Good Thing To Do.  <div><br></div><div>Much of the usage in the test suite, with fewer occurrences present in the main code base.  So this makes it easier to clean up the main code base, which is the priority.</div><div><br></div><div>Not backporting the changes may make it harder in the future to port bug fixes and improvements to older major versions.  We don't promise ABI stability for the C++ API, so I'm not sure whether this is a real concern?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2025 at 5:52 AM Daniel Baston <<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Martin,<br></div><div><br></div><div>I avoid the typedefs for 
the same reasons you listed, but they seem to be rarely used outside of 
unit tests (grep shows 97 lines with "Ptr" under "src" and 825 lines 
under "tests"). I'm not sure if a purge is the highest priority for 
improving the test suite, but am not opposed if others want to take that
 on. I would not be in favor of backporting this type of change, which 
would break the API in a minor release while offering no benefit to 
users.<br></div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2025 at 7:16 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">The GEOS codebase has several typedefs called GeometryPtr and GeomPtr.  They are aliases for a mixture of Geometry * and std::unique_Ptr<Geometry>. I'm thinking it's a good thing to purge them from the codebase in favour of explicit type signatures, because:</div><div dir="ltr"><br></div><div dir="ltr">- it's highly confusing that they can be aliases for different things</div><div>- it's complicated that they are defined in multiple places</div><div dir="ltr">- it can be hard to see what they represent</div><div dir="ltr">- they don't save much typing in the case of Geometry*, and using auto can simplify other uses</div><div dir="ltr"><div><br></div><div>This was discussed a while back.  The general feeling was that it's better to use explicit types.  Is this still the consensus?</div><div><br></div><div>Some notes on the process:</div><div>- I expect this will be done in multiple passes, to fit work schedules.  Will start with the least intrusive changes</div><div>- when this is done, it needs to be backported so that subsequent backports don't collide with unchanged code.</div><div>- If older versions use the aliases in dead code, it may not be removed, just patched to ensure it still compiles (i.e. by leaving the typedefs in place)</div><div> </div><div><br></div><div><br></div><div><div><br></div></div></div>
</div>
</blockquote></div>
</blockquote></div>
</blockquote></div>