Re: sumtype 0.8.3

2019-03-03 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 3 March 2019 at 14:32:55 UTC, Jacob Shtokolov wrote: On Monday, 25 February 2019 at 20:31:43 UTC, Paul Backus wrote: - Pattern matching, including support for structural matching (★) What is the main difference between 'match()' in this library and 'visit()' in std.variant?

Re: sumtype 0.8.3

2019-02-26 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 26 February 2019 at 12:52:11 UTC, JN wrote: On Monday, 25 February 2019 at 20:31:43 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Is it a better alternative? Seems like it from the description. If

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Paul Backus via Digitalmars-d-announce
On Monday, 25 February 2019 at 20:41:58 UTC, Paolo Invernizzi wrote: Honestly, I've not understood the rationale or the covered use case in letting the copy ctor mutate the ref source parameters... Sincerely, without polemical intent. - P Because D's const is transitive, you can't

sumtype 0.8.3

2019-02-25 Thread Paul Backus via Digitalmars-d-announce
SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (★) - Self-referential types, using `This` - Works with pure, @safe, @nogc, and immutable (★) - Zero runtime

Re: taggedalgebraic 0.11.0 adds TaggedUnion

2019-02-23 Thread Paul Backus via Digitalmars-d-announce
On Friday, 22 February 2019 at 17:09:41 UTC, Sönke Ludwig wrote: - Behaves like a POD if only POD fields exist, is non-copyable if any contained type is non-copyable etc. In fact, if a contained type is non-copyable, it fails to compile altogether. (Example code below.) Granted, so do

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-02-04 Thread Paul Backus via Digitalmars-d-announce
On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote: On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes Scherkl wrote: I don't understand this. What does "(return)?" mean? Is this valid D syntax? What do I miss? I meant for that to be interpreted like a Regular expression,

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-02-01 Thread Paul Backus via Digitalmars-d-announce
On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote: At no point is the compiler aware that the user intends for x to be interpreted as a getter. In theory, at least, that's what @property is for.

Re: Bitblob (hash wrapper) & Minivariant (tagged union) dub packages

2019-01-22 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 22 January 2019 at 10:26:33 UTC, Mathias Lang wrote: ## Minivariant https://github.com/Geod24/minivariant Minivariant is a "works for me" replacement of `std.variant : Algebraic`. [...] I looked into fixing it, but given Variant's design (which relies heavily on `TypeInfo`) it

Re: D-lighted, I'm Sure

2019-01-19 Thread Paul Backus via Digitalmars-d-announce
On Saturday, 19 January 2019 at 22:07:47 UTC, Ron Tarrant wrote: On Friday, 18 January 2019 at 18:59:59 UTC, JN wrote: Just add a line in your dub.json file and you have the library. Need to upgrade to newer version? Just change the version in dub.json file. Need to download the problem from

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-18 Thread Paul Backus via Digitalmars-d-announce
On Friday, 18 January 2019 at 20:03:48 UTC, Mark wrote: [...] Represent types as strings, CTFE them as you see fit, and output a string that can then be mixin'ed to use the actual type. :) Two problems: 1) Mixing in a string is unhygienic. If two modules (or two scopes in the same module)

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Paul Backus via Digitalmars-d-announce
On Thursday, 17 January 2019 at 16:06:39 UTC, bpr wrote: On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote: Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a presentation at NWCPP where he wrote a few lines of Haskell code. Then, he showed the same code

Re: My Meeting C++ Keynote video is now available

2019-01-14 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote: Quote from article: "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and

Re: My Meeting C++ Keynote video is now available

2019-01-14 Thread Paul Backus via Digitalmars-d-announce
On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: Is it possible to declare a function whose name is a CTFE computed string? Yes, if you do it with a string mixin.

Re: My Meeting C++ Keynote video is now available

2019-01-13 Thread Paul Backus via Digitalmars-d-announce
On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote: What I wonder is, with design by introspection and the right mix of other language features (e.g. `alias`, `alias this`, mixins, etc...), what traditional language features can be removed from the compiler and delegated to

Re: A brief survey of build tools, focused on D

2018-12-15 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote: It's time we came back to the essentials. Current monolithic build systems ought to be split into two parts: (1) Dependency detector / DAG generator. Do whatever you need to do here: dub-style scanning of .d imports, scan

Re: sumtype 0.7.0

2018-11-21 Thread Paul Backus via Digitalmars-d-announce
On Thursday, 22 November 2018 at 00:02:18 UTC, H. S. Teoh wrote: Any way this could be expanded to arbitrary types like Variant? Or is that not possible without reverting to TypeInfo dependency? T Not possible, unfortunately--for that and other reasons.

sumtype 0.7.0

2018-11-20 Thread Paul Backus via Digitalmars-d-announce
SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (★) - Self-referential types, using `This` - Works with pure, @safe, @nogc, and immutable (★) - Zero runtime

Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright

2018-11-05 Thread Paul Backus via Digitalmars-d-announce
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity wrote: ok. Now, what are your options then (assuming you want an independent type)? (option 1) define one encapsulated type, per module. (option 2) have a means for type independence within a module - i.e. selective hiding. D

Re: lodash like utility/algorithms library for D

2018-09-30 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 30 September 2018 at 22:17:05 UTC, aliak wrote: On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus wrote: I agree that this is useful, but why not just return a naked `SumType!(string, JSONError)` in that case? Is there some additional value added by the `Expect` wrapper

Re: lodash like utility/algorithms library for D

2018-09-29 Thread Paul Backus via Digitalmars-d-announce
On Saturday, 29 September 2018 at 12:40:14 UTC, aliak wrote: I.e. by allowing you to define the unexepcted you could for instance: enum JSONError { invalidKey, notString, notNumber } auto a = parse(jsonData); a.getAsString("key").match!( (string value) => // yay (JSONError error)

Re: lodash like utility/algorithms library for D

2018-09-28 Thread Paul Backus via Digitalmars-d-announce
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote: Hi, [...] Lots of good stuff here! I'm curious about your approach to `Expect`, since I've written a version of it myself. How useful have you found being able to use unexpected values of any type, as opposed to just exceptions?

Re: expectations 0.1.0

2018-09-05 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 4 September 2018 at 22:08:48 UTC, Nick Sabalausky (Abscissa) wrote: I think you may be getting hung up on a certain particular detail of Vladimir's exact "draft" implementation of Success, whereas I'm focusing more on Success's more general point of "Once the object is no longer

Re: expectations 0.1.0

2018-09-04 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo

Re: expectations 0.1.0

2018-09-03 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) wrote: By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothing happens. That's called squelching an

Re: expectations 0.1.0

2018-09-03 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa) wrote: Note that the above has *nothing* to do with retrieving a value. Retrieving a value is merely used by the implementation as a trigger to lazily decide whether the caller wants `foo` or `tryFoo`. Going out of scope

Re: expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: Please correct me if I'm wrong, but from looking at the code, given e.g.: Expected!void copyFile(string from, string to); nothing prevents me from writing: void main() { copyFile("nonexistent", "target"); } The success

Re: expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 2 September 2018 at 23:38:41 UTC, Per Nordlöw wrote: On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed

expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

2018-08-24 Thread Paul Backus via Digitalmars-d-announce
On Friday, 24 August 2018 at 20:59:34 UTC, aliak wrote: THis is true. And might be interesting to try out actually. Can you access the types in a SumType via index? I'm thinking because Optional behaves like a range, and I guess I'd define a SumType!(T, None), then a rough outline may be:

Re: sumtype 0.5.0

2018-08-22 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. New point release, 0.5.3, with the following updates: - SumType now uses the smallest possible integer type for its tag (e.g.,

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

2018-08-22 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 22 August 2018 at 22:11:05 UTC, aliak wrote: On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote: It's interesting that both sumtype and optional have match templates. Maybe scope to combine these projects? That'd be cool. Optional uses .match on a "some" or "none" range,

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

2018-08-16 Thread Paul Backus via Digitalmars-d-announce
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote: Hi See: https://optional.dub.pm Looks great! auto john = some(new Person()); Would it also work to leave off the `some` here and skip the first `dispatch` in the following lines? (i.e., make `john` a `Person` rather than an

Re: sumtype 0.5.0

2018-08-10 Thread Paul Backus via Digitalmars-d-announce
On Friday, 10 August 2018 at 21:28:40 UTC, Everlast wrote: Yes, but alias Z = SumType.Union(X,Y); is not the same as alias Z = SumType!(int, float, string, complex, vector). In the first case Z is actually a union of 2 types while in the second it is of 5. There is a subtle difference

Re: sumtype 0.5.0

2018-08-10 Thread Paul Backus via Digitalmars-d-announce
On Friday, 10 August 2018 at 13:11:13 UTC, Everlast wrote: On Friday, 10 August 2018 at 12:35:18 UTC, Everlast wrote: It would be nice if some actual examples could be given. The help on dub is a bit confusing because the the code is not complete. In addition to the example on the dub

Re: sumtype 0.5.0

2018-08-09 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Version 0.5.2, with fixes for the bugs reported in this thread, is now available. Thanks to vit for their detailed feedback!

Re: sumtype 0.5.0

2018-08-09 Thread Paul Backus via Digitalmars-d-announce
On Thursday, 9 August 2018 at 07:52:12 UTC, vit wrote: SumType without initialization doesn't fail if first type has @disabled this(). It did fail for me, but it also failed *with* initialization too, so there was definitely a bug there. method toString is not template. (why is there in the

Re: sumtype 0.5.0

2018-08-08 Thread Paul Backus via Digitalmars-d-announce
On Thursday, 9 August 2018 at 00:11:22 UTC, Seb wrote: On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote: (It uses the version from DUB and updates itself once daily, but somehow dub still lists 0.4.1 at the moment) It looks like you didn't push the git tag to GitHub:

Re: sumtype 0.5.0

2018-08-08 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 8 August 2018 at 21:57:07 UTC, vit wrote: Nice, but destructor SumType.~this() can call destroy on reference type like class: Whoops. Good catch. I've pushed a fix, tagged as version 0.5.1.

sumtype 0.5.0

2018-08-08 Thread Paul Backus via Digitalmars-d-announce
SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (*) - Self-referential types, using `This` - Works with `pure`, `@safe`, `@nogc`, and `immutable` (*) - Zero

Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages

2018-05-21 Thread Paul Backus via Digitalmars-d-announce
On Monday, 21 May 2018 at 14:48:23 UTC, Mike Parker wrote: Nick Sabaluasky's first post to the D Blog is a tip on how to create an aliased type that keeps its name in error messages. I'm not sure making `_data` private is really a good idea. For example, this only works if `_data` is public:

Re: sumtype 0.3.0

2018-05-09 Thread Paul Backus via Digitalmars-d-announce
On Wednesday, 9 May 2018 at 13:33:44 UTC, jmh530 wrote: On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote: [snip] - Zero runtime overhead compared to hand-written C Just to clarify, would the run-time performance of the length function in the example be equivalent to if it had been

Re: sumtype 0.3.0

2018-05-08 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 8 May 2018 at 06:33:38 UTC, TheGag96 wrote: Wow.. without comments and unittests, the implementation is only 116 lines. Awesome job. Even now I still find it incredible what D can do. Is Algebraic in the standard library really that bad? And if so, why aren't implementations like

Re: sumtype 0.3.0

2018-05-07 Thread Paul Backus via Digitalmars-d-announce
On Monday, 7 May 2018 at 19:28:16 UTC, Sönke Ludwig wrote: Another similar project: http://taggedalgebraic.dub.pm/ There's also tagged_union and minivariant on dub, that I've found. I'm definitely far from the first person to be dissatisfied with `Algebraic`, or to try my hand at writing a

Re: sumtype 0.3.0

2018-05-07 Thread Paul Backus via Digitalmars-d-announce
On Monday, 7 May 2018 at 09:23:04 UTC, Brian Schott wrote: I spent several hours trying to get this working with a non-trivial AST, and I think that it just isn't going to work until the compiler front-end gets better about handling recursive definitions. It fails in more-or-less the same way

sumtype 0.3.0

2018-05-06 Thread Paul Backus via Digitalmars-d-announce
SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (*) - Self-referential types, using `This` - Works with `pure`, `@safe`, `@nogc`, and `immutable` (*) - Zero