Thanks for the feedback Alex.
As far as:
> If you wanted to file a jira on anything here, a jira to add a line to
the doc string stating that the first duplicate is kept would be the only
thing possibly worth doing.
I'll get one logged then.
On Saturday, December 31, 2016 at 12:05:16 PM UTC-
Replying to many things in this thread at once here...
Re lazy sequences, I think you can take it as implicit and rely on the
input seq order is retained (same as other sequence functions).
Re duplicates, the current implementation retains the first element, but as
mentioned this is not stated
Yeah, I was thinking about logging the ticket for it. I just figured I'd
discuss it on the google groups first to see if anyone else thought it was
a useful concern.
It seems that some people have opinions on in it in both directions
perhaps, i.e. docs are sufficient vs docs are not sufficient.
On Thursday, December 29, 2016 at 5:47:14 PM UTC-6, Erik Assum wrote:
>
> Wouldn't the order be different depending on wether you keep the first or
> the last?
>
> (distinct [1 2 1])
> => [1 2]
> vs
> (distinct [1 2 1])
> => [2 1]
>
> Erik.
> --
> i farta
>
>
I should have thought about this sce
I was trying to understand part 2 of the OP’s question (per the piece I had
quoted in my response).
Part 1 of the OP’s question is pretty clear cut: the order of the result
depends on which element is kept.
Given that, if you *don’t* care about the order, you could use `set` instead of
`
How about a ticket for enhancement of the API documentation to clarify
the nature of distinct's parameter (any seqable, even lazy)? That would
distinguish it from, e.g., (dedupe (sort coll)).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to
Wouldn't the order be different depending on wether you keep the first or the
last?
(distinct [1 2 1])
=> [1 2]
vs
(distinct [1 2 1])
=> [2 1]
Erik.
--
i farta
> Den 29. des. 2016 kl. 22.32 skrev Sean Corfield :
>
> Can you provide a scenario when it matters? Given that you had two immutabl
> f it helps anyone sleep better at night, were the behavior of distinct ever
> to change in a way that breaks one's application, the original one is right
> there in the git history, available for everyone's copying and use, with
> whatever promises in the doc string you choose to add.
I under
Yeah. It is so hard to come up with a real use case here after I think about it
that it is best to just let it be.
It would only matter if identity mattered for something, but still hard to even
contrive a scenario. So part (2) solved.
--
You received this message because you are subscribed
On Thu, Dec 29, 2016 at 1:32 PM, Sean Corfield wrote:
>
> > I'm just guessing there the answer may just be "equal values are equal
> and you should never care which one you get out". There are times to care
> though, but then perhaps just don't use `distinct` or be sure to have a
> test on it.
If it helps anyone sleep better at night, were the behavior of distinct
ever to change in a way that breaks one's application, the original one is
right there in the git history, available for everyone's copying and use,
with whatever promises in the doc string you choose to add.
Andy
On Thu, Dec
> I'm just guessing there the answer may just be "equal values are equal and
> you should never care which one you get out". There are times to care
> though, but then perhaps just don't use `distinct` or be sure to have a test
> on it. :P
Can you provide a scenario when it matters? Given
Yeah, adding a test for undocumented behavior seems somewhat reasonable. I
do wish the docs would be a bit clearer on these aspects of the contract.
Without that it just doesn't seem that there is any real commitment to the
Clojure implementation to not change later.
I understand the general
This is one of those odd questions where the answer of what "could" happen
and what "will most likely happen" are completely different. There is no
reason why `distinct` should reorder or which item will be preserved.
However there's really only one logical way to implement this (the way it's
curre
Also, I'm assuming distinct uses .equals semantics which might be worth
calling out in the doc
On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez wrote:
> The doc for `distinct` is:
> "Returns a lazy sequence of the elements of coll with duplicates removed.
> Returns a stateful transducer when no c
The doc for `distinct` is:
"Returns a lazy sequence of the elements of coll with duplicates removed.
Returns a stateful transducer when no collection is provided."
(1) In the lazy sequence case, I've thought that maybe it is assuemd there
is a guarantee that the order of the input seq is preser
16 matches
Mail list logo
