Re: An optional/maybe type with range semantics

2018-03-01 Thread aliak via Digitalmars-d-announce
On Wednesday, 28 February 2018 at 10:55:38 UTC, Andrei Alexandrescu wrote: On 2/28/18 12:54 PM, Andrei Alexandrescu wrote: On 2/25/18 8:03 PM, aliak wrote: Did you take a look at https://dlang.org/library/std/range/only.html? -- Andrei Ah, sorry I missed that you mentioned it. -- Andrei

Re: An optional/maybe type with range semantics

2018-02-28 Thread Andrei Alexandrescu via Digitalmars-d-announce
On 2/28/18 12:54 PM, Andrei Alexandrescu wrote: On 2/25/18 8:03 PM, aliak wrote: Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or

Re: An optional/maybe type with range semantics

2018-02-28 Thread Andrei Alexandrescu via Digitalmars-d-announce
On 2/25/18 8:03 PM, aliak wrote: Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or features, or bad design or potential for better designs

Re: An optional/maybe type with range semantics

2018-02-27 Thread aliak via Digitalmars-d-announce
On Tuesday, 27 February 2018 at 11:58:34 UTC, Dukc wrote: On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote: Guess I could do a pointer and call new when i need to store a value instead. Or maybe it's better to do it like above and store as value type with default value and a boolean at

Re: An optional/maybe type with range semantics

2018-02-27 Thread Dukc via Digitalmars-d-announce
On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote: Guess I could do a pointer and call new when i need to store a value instead. Or maybe it's better to do it like above and store as value type with default value and a boolean at the site. Not sure. You do not need a separate boolean

Re: An optional/maybe type with range semantics

2018-02-26 Thread Meta via Digitalmars-d-announce
On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote: Meta: Is this your stuff btw? -> https://github.com/skirino/d-option :) me thinks I may have gotten some inspiration from you if so, so thanks! Nope. I'm MetaLang on Github.

Re: An optional/maybe type with range semantics

2018-02-26 Thread aliak via Digitalmars-d-announce
On Monday, 26 February 2018 at 16:02:58 UTC, Dukc wrote: I kinda start to see the idea... Granted, nullable is in a way a range that can hold exactly one or exactly zero elements. Not a bad idea at all. Aye, ranges do not need nullability indeed. Optional doesn't need to adhere to the

Re: An optional/maybe type with range semantics

2018-02-26 Thread Dukc via Digitalmars-d-announce
On Monday, 26 February 2018 at 15:27:11 UTC, Meta wrote: The idea is to treat `Option!T` as a regular input range so it can be used with all the regular range algorithms without special casing it. You're right in that the null/non-null dichotomy is equivalent to the notion of a range being

Re: An optional/maybe type with range semantics

2018-02-26 Thread Meta via Digitalmars-d-announce
On Monday, 26 February 2018 at 15:21:27 UTC, Dukc wrote: Honestly, I fail to see the idea behind this... Ranges do not need any nullability on top of them IMO, because an empty range can already be used to denote a kind of "default", "unassigned" or "nothing" - type of value. On the other

Re: An optional/maybe type with range semantics

2018-02-26 Thread Dukc via Digitalmars-d-announce
On Sunday, 25 February 2018 at 18:03:35 UTC, aliak wrote: Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or features, or bad design or

An optional/maybe type with range semantics

2018-02-25 Thread aliak via Digitalmars-d-announce
Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or features, or bad design or potential for better designs from anyone who's interested :)