On Monday, 5 April 2021 at 21:43:30 UTC, Paul Backus wrote:
>No, because it's not my package, it's Ali Akhtarzada's.
Is there a place for it in Phobos?
April 05, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Monday, 5 April 2021 at 21:43:30 UTC, Paul Backus wrote: >No, because it's not my package, it's Ali Akhtarzada's. Is there a place for it in Phobos? |
April 05, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Monday, 5 April 2021 at 22:21:39 UTC, Per Nordlöw wrote: >On Monday, 5 April 2021 at 21:43:30 UTC, Paul Backus wrote: >No, because it's not my package, it's Ali Akhtarzada's. Is there a place for it in Phobos? I think there's a place for something like it in Phobos. Whether that's |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Friday, 26 March 2021 at 15:12:04 UTC, Paul Backus wrote: >On Friday, 26 March 2021 at 13:38:01 UTC, vitoroak wrote: >I think one reason is that unlike Rust, D doesn't have a safe way to return I believe with DIP 1000 it should be possible to return something like When I experimented with Of course the ideal would be to make If you look at all the exceptions C++ has for its reference type constructor, you'll immediately see why Walter created |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Q. Schroll | On Tuesday, 6 April 2021 at 01:47:47 UTC, Q. Schroll wrote: >On Friday, 26 March 2021 at 15:12:04 UTC, Paul Backus wrote: >Of course the ideal would be to make If you look at all the exceptions C++ has for its reference type constructor, you'll immediately see why Walter created Here's what the generic identity function currently looks like in D:
Here's what the generic identity function would look like if
I rest my case. |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Tuesday, 6 April 2021 at 02:14:17 UTC, Paul Backus wrote: >Here's what the generic identity function would look like if
I rest my case. So what was the motive for not making it a type qualifier in D? And what are the obstacles for making it that? |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Tuesday, 6 April 2021 at 20:34:08 UTC, Per Nordlöw wrote: >So what was the motive for not making it a type qualifier in D? And what are the obstacles for making it that? See https://forum.dlang.org/post/mailman.7903.1554072555.29801.digitalmars-d@puremagic.com |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Tuesday, 6 April 2021 at 02:14:17 UTC, Paul Backus wrote: >
When is the call to forward needed in this case? |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Tuesday, 6 April 2021 at 20:47:31 UTC, Per Nordlöw wrote: >On Tuesday, 6 April 2021 at 02:14:17 UTC, Paul Backus wrote: >
When is the call to forward needed in this case? For non-copyable types. It's actually needed in both cases--we would need DIP 1040 (or something similar) to get rid of it. |
April 06, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Tuesday, 6 April 2021 at 21:09:13 UTC, Paul Backus wrote: >For non-copyable types. It's actually needed in both cases--we would need DIP 1040 (or something similar) to get rid of it. So let's help Walter getting DIP-1040 accepted then. :) What else is forward needed for? The doc says "Forwards function arguments while keeping Why can't the compiler do that for us? |
April 07, 2021 Re: Motive behind !empty() with front() instead of Optional front() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On 2021-04-05 22:01, Per Nordlöw wrote: > Interesting. Can you show some pseudocode of this? Can those algorithms be implemented as non-member functions? Here's an article about idiomatic Scala and optional types [1]. I think it applies to D as well. [1] https://www.originate.com/thinking/idiomatic-scala-your-options-do-not-match -- /Jacob Carlborg |