digitalmars.D - Seeking help with opend std
- monkyyy (20/20) Dec 27 2024 https://github.com/opendlang/d/issues/4
- monkyyy (4/4) Jan 10 On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:
- Elias (0xEAB) (2/3) Jan 10 You should probably clarify on that.
- Andrea Fontana (2/7) Jan 11 Nice filename, anyway.
- Anton Pastukhov (3/8) Jan 12 Please make popFront and popBack actually return popped values
- monkyyy (3/14) Jan 12 Even if I liked that idea, wouldnt that break phoboes
- Anton Pastukhov (6/22) Jan 13 My uninformed opinion is that shouldn't cause too much trouble?
- =?UTF-8?Q?Ali_=C3=87ehreli?= (17/27) Jan 13 Historically that did not work at a time when
- Anton Pastukhov (13/45) Jan 14 This is just a matter of ergonomics.
- Anton Pastukhov (5/7) Jan 14 This is a small inconvenience, but it's also a solved problem in
https://github.com/opendlang/d/issues/4 I added the labels `good first issue` and `help wanted`; therefore its a good first issue and I'm good at open source and communicating --- Id like help, most of the people in opend are specifically generic-code non-believers and its *allot* of code I want to get just werk`n. If anyone wants to rant discussions should happen here: https://github.com/orgs/opendlang/discussions/46 Gists, stealing code from projects, *I dont care* about the formality of holy git, style, or even lawyers opinions on if russia is gnu compliment. I view the following as the important factors for making programming ever actually good: 1. data structures 2. algorithm (including searching algorithms, experimenting with apis) 3. better printf debugging 4. sane serialization
Dec 27 2024
On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Still want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 10
Elias (0xEAB) <desisma heidel.beer> On Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:from the usual suspectsYou should probably clarify on that.
Jan 10
On Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Nice filename, anyway.Still want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 11
On Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Please make popFront and popBack actually return popped values thanksStill want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 12
On Sunday, 12 January 2025 at 19:25:37 UTC, Anton Pastukhov wrote:On Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:Even if I liked that idea, wouldnt that break phoboes compatibility?On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Please make popFront and popBack actually return popped values thanksStill want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 12
On Sunday, 12 January 2025 at 20:40:06 UTC, monkyyy wrote:On Sunday, 12 January 2025 at 19:25:37 UTC, Anton Pastukhov wrote:My uninformed opinion is that shouldn't cause too much trouble? popFront and popBack currently return void, so it's safe to assume there are no places in the existing code that expect a return value, so it's just going to be discarded. I could be terribly wrong ofcOn Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:Even if I liked that idea, wouldnt that break phoboes compatibility?On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Please make popFront and popBack actually return popped values thanksStill want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 13
On Monday, 13 January 2025 at 12:26:07 UTC, Anton Pastukhov wrote:My uninformed opinion is that shouldn't cause too much trouble? popFront and popBack currently return void, so it's safe to assume there are no places in the existing code that expect a return value, so it's just going to be discarded.It would break this mini implementation of `map`: ```D private struct MapResult(alias func, R) { R r; auto front() => func(r.front); bool empty() => r.empty; void popFront() => r.popFront(); } ```
Jan 13
On Monday, 13 January 2025 at 12:26:07 UTC, Anton Pastukhov wrote:My uninformed opinion is that shouldn't cause too much trouble? popFront and popBack currently return void, so it's safe to assume there are no places in the existing code that expect a return value, so it's just going to be discarded. I could be terribly wrong ofcYou can do this: ```d void fn1(){} void fn2(){ return fn1(); }
Jan 13
On Monday, 13 January 2025 at 12:26:07 UTC, Anton Pastukhov wrote:On Sunday, 12 January 2025 at 20:40:06 UTC, monkyyy wrote:I believe phoboes and "contract programming" to break code that should otherwise work(I know of spefic examples where coping and pasting the function without the contract compiles) Its possible to detect differences here and the real code range api that actually being used by phoebes is actually oo-y If you care about the api I could add some variant of this function: ```d auto ref next(R)(R r){ auto e=&(r.front); r.popFront; return *e; } ``` (would need to test several situation to find version that actually works with both ref and nonref front)On Sunday, 12 January 2025 at 19:25:37 UTC, Anton Pastukhov wrote:My uninformed opinion is that shouldn't cause too much trouble? popFront and popBack currently return void, so it's safe to assume there are no places in the existing code that expect a return value, so it's just going to be discarded. I could be terribly wrong ofcOn Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:Even if I liked that idea, wouldnt that break phoboes compatibility?On Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Please make popFront and popBack actually return popped values thanksStill want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 13
On 1/12/25 11:25 AM, Anton Pastukhov wrote:On Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:Historically that did not work at a time when - C++ was the ruler - Strong exception guarantee mattered - Move constructors were not available T popFront() { /* ... */ // 1) Mutate the range return front; // 2) Copy the element } The problem is with copying that popped value. If the copying itself throws, the range is already modified. Such topics have been covered extensively in books like Exceptional C++ by Herb Sutter. If strong exception guarantee is indeed needed, the correct API is to provide front() and popFront() separately. But once you have front() anyway, why conflate the two actions of popping and providing in popFront() again? So the current D InputRange API works. AliOn Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Please make popFront and popBack actually return popped values thanksStill want help https://github.com/opendlang/d/blob/main/source/odc/algorthims.d will take criticism from the usual suspects
Jan 13
On Monday, 13 January 2025 at 21:29:38 UTC, Ali Çehreli wrote:On 1/12/25 11:25 AM, Anton Pastukhov wrote:This is just a matter of ergonomics. ```d auto x = myArr.popFront(); ``` is slightly more convenient than ```d myArr.popFront() auto x = myArr.front; ``` Re: exceptions, for builtin range data types it's realistic to give nothrow guarantee. For user-defined types, it's responsibility of the user to take care of itOn Saturday, 11 January 2025 at 05:12:02 UTC, monkyyy wrote:https://github.com/opendlang/d/blob/main/source/odc/algorthims.dOn Friday, 27 December 2024 at 21:15:40 UTC, monkyyy wrote:Still want helpvalues thanks Historically that did not work at a time when - C++ was the ruler - Strong exception guarantee mattered - Move constructors were not available T popFront() { /* ... */ // 1) Mutate the range return front; // 2) Copy the element } The problem is with copying that popped value. If the copying itself throws, the range is already modified. Such topics have been covered extensively in books like Exceptional C++ by Herb Sutter. If strong exception guarantee is indeed needed, the correct API is to provide front() and popFront() separately. But once you have front() anyway, why conflate the two actions of popping and providing in popFront() again? So the current D InputRange API works. Aliwill take criticism from the usual suspectsPlease make popFront and popBack actually return popped
Jan 14
On Tuesday, 14 January 2025 at 11:19:50 UTC, Anton Pastukhov wrote:On Monday, 13 January 2025 at 21:29:38 UTC, Ali Çehreli wrote:This is a small inconvenience, but it's also a solved problem in many other languages. E.g. in Rust, `Vec.pop` behaves exactly like thatOn 1/12/25 11:25 AM, Anton Pastukhov wrote:
Jan 14