Re: List container strawman 1.2

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

I guess if your compiler is that smart, it could be a good thing. The flag
is probably not too bad a deal since it has a default. Defining equality is
of questionable value/pain since the element type was private - do you want
to force someone to define equality in every instance?

I don't know that this would be the best answer anyway. If you have a need
for unique and non-unique lists, then you've just duplicated the code
anyway, so you don't save anything on the optimization - and probably lose
more space along the way. If at some times you want your list object to be
unique and at other times non-unique (Say, if what you are storing in the
list is something the user may express a preference about) then you've got
to get two lists to work with.

Granted, maintaining a flag allows for the possibility that someone might be
having a Blonde Moment and switch the flag back and forth causing a required
unique list to have non-unique items (do you check this on state change?).
There's always something getting in the way.

An alternative might be to make a child of the basic list package that adds
the capability. (type Unique_List is new List with private....) I would just
favor making sure we have a nice simple basic list package without too many
dingleberries hanging off of it so it satisfies some large percentage of the
uses as simply and painlessly as possible. If there are interesting
variants, it seems better to include them as children or different branches.

Just my $0.02.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
news:3beffc62@pull.gecm.com...
>
> Well, the biggest benefit we found with this method was that it allowed
> the compiler to optimise away various paths on instantiation depending on
> the
> parameter passed. You could always have:
>
>     Elements_Must_Be_Unique : Boolean := False;
>
> The actual code difference between the two variants is very small and
would
> save having two package sources to maintain, which would have (almost)
> exactly
> the same specification.
>
>