January 04, 2022

On Monday, 3 January 2022 at 00:15:53 UTC, Era Scarecrow wrote:

>

Then maybe we in should be implemented; Have it check if you have it sorted (unless you do assumesorted template). If it is sorted naturally use BinarySearch, and if not it would probably do a linear search BUT give a warning message and file/line number so it can be fixed/traced? (Or just make it have to be Binary Search and asserts out if it isn't sorted)

As for bool vs pointer return... probably return a pointer as that can easily be tested as bool for no extra cost.

It would make sense to implement in for SortedRange, but there is no use case for returning a pointer. You already have the value on the left hand side, the only reason for a pointer would be to mutate the element in the range. Mutating that would potentially stop the range being in order, violating the point of SortedRange.

January 05, 2022

On Tuesday, 4 January 2022 at 18:23:33 UTC, Nick Treleaven wrote:

>

It would make sense to implement in for SortedRange, but there is no use case for returning a pointer. You already have the value on the left hand side, the only reason for a pointer would be to mutate the element in the range.

Sorry, i was somehow thinking there was a key/value pair in this and not just a normal sorted block.

But yes there may still be use cases. Consider i do opCmp on a struct, and it only does comparisons on say a name portion (Or UPC or some other immutable property ID), but no other part of the stored data. The name/ID would be how it's sorted; But any attached data which is non-sorted would be inaccessible otherwise. This could be phone number, address, grades, just about anything (and those items could be changed without changing the sorting order)

Though you can probably do 2 steps it seems like a bit of extra pointless work to me. Or maybe AA's are a better choice in that case. I'm not sure.

January 07, 2022

On Wednesday, 29 December 2021 at 21:18:30 UTC, Paul Backus wrote:

>

Seems like an issue worth filing a bugzilla report about.

I am not able to register for issues.dlang.org, does not not accept gmail accounts. I guess someone else has to file it.

January 07, 2022

On Friday, 7 January 2022 at 10:07:02 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 29 December 2021 at 21:18:30 UTC, Paul Backus wrote:

>

Seems like an issue worth filing a bugzilla report about.

I am not able to register for issues.dlang.org, does not not accept gmail accounts. I guess someone else has to file it.

Is that real? That gmail accounts don't work? That's so odd.

January 07, 2022

On Friday, 7 January 2022 at 10:07:02 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 29 December 2021 at 21:18:30 UTC, Paul Backus wrote:

>

Seems like an issue worth filing a bugzilla report about.

I am not able to register for issues.dlang.org, does not not accept gmail accounts. I guess someone else has to file it.

I registered with a gmail account. What error do you see?

January 07, 2022

On Friday, 7 January 2022 at 10:45:39 UTC, Mike Parker wrote:

>

On Friday, 7 January 2022 at 10:07:02 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 29 December 2021 at 21:18:30 UTC, Paul Backus wrote:

>

Seems like an issue worth filing a bugzilla report about.

I am not able to register for issues.dlang.org, does not not accept gmail accounts. I guess someone else has to file it.

I registered with a gmail account. What error do you see?

«The e-mail address you entered (firstname.middlename.lastname@gmail.com) didn't pass our syntax checking for a legal email address. A legal address must contain exactly one '@', and at least one '.' after the @. Currently, registering using Gmail addresses is not allowed due to spam. It also must not contain any illegal characters.»

January 07, 2022

On Wednesday, 5 January 2022 at 23:16:48 UTC, Era Scarecrow wrote:

>

Consider i do opCmp on a struct, and it only does comparisons on say a name portion

Ok, you're right. The search key then wouldn't need to contain the other data which is not used for comparisons.

>

But any attached data which is non-sorted would be inaccessible otherwise. This could be phone number, address, grades, just about anything (and those items could be changed without changing the sorting order)

True, but if SortedRange exposed a pointer to the matching element, it should probably be const so the data that is compared is not changed. (It could perhaps alternatively return a one-based index instead, which would convert to bool as expected).

1 2 3 4 5
Next ›   Last »