On 1/15/19 4:37 AM, Martin Tschierschke wrote:
> On Monday, 14 January 2019 at 18:52:02 UTC, Jacob Carlborg wrote:
>> On 2019-01-14 15:42, Steven Schveighoffer wrote:
>>
>>> That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends.
>>
>> Exactly, and I don't need five minutes for that. Five seconds is enough :)
> Ok, bad example,  but let's say you want ORM mapping, too and to have the ability to switch to Postgres later? So what would you recommend?

I should have said that your point is mostly correct, just that this is a bad example :)

I've looked for ORM on code.dlang.org, and never found one yet that I liked. So the answer would take infinite seconds to complete.

But let's say we put ORM into Phobos. Certainly, it would get heavy use, but I would be likely to believe that it would not cover the problem space completely, and leave quite a bit to be desired.

I think that there are some things that can go into the standard library and live there happily. There are other things that should be left to the community, even though they are essential, simply because locking into one implementation/API/idea is too restrictive.

-Steve

On Wednesday, 16 January 2019 at 14:59:20 UTC, Steven Schveighoffer wrote:
> On 1/15/19 4:37 AM, Martin Tschierschke wrote:
>> [...]
>
> I should have said that your point is mostly correct, just that this is a bad example :)
>
> I've looked for ORM on code.dlang.org, and never found one yet that I liked. So the answer would take infinite seconds to complete.
>
> But let's say we put ORM into Phobos. Certainly, it would get heavy use, but I would be likely to believe that it would not cover the problem space completely, and leave quite a bit to be desired.
>
> I think that there are some things that can go into the standard library and live there happily. There are other things that should be left to the community, even though they are essential, simply because locking into one implementation/API/idea is too restrictive.
>
> -Steve

+1

I'm waiting, for example, for a revamp of IO, just to start...

--- Paolo

On 1/16/19 10:06 AM, Paolo Invernizzi wrote:

> I'm waiting, for example, for a revamp of IO, just to start...

We're working on it...

https://github.com/schveiguy/iopipe
https://github.com/MartinNowak/io

-Steve

On Wednesday, 16 January 2019 at 16:30:17 UTC, Steven Schveighoffer wrote:
> On 1/16/19 10:06 AM, Paolo Invernizzi wrote:
>
>> I'm waiting, for example, for a revamp of IO, just to start...
>
> We're working on it...
>
> https://github.com/schveiguy/iopipe
> https://github.com/MartinNowak/io
>
> -Steve

I was exactly referring to that two... they are great, and I've used both!
Despite that, they seem stalled: any plan to go ahead in the medium term?

Thanks for your work (and to Martin too)

---
Paolo

On 1/16/19 11:43 AM, Paolo Invernizzi wrote:
> On Wednesday, 16 January 2019 at 16:30:17 UTC, Steven Schveighoffer wrote:
>> On 1/16/19 10:06 AM, Paolo Invernizzi wrote:
>>
>>> I'm waiting, for example, for a revamp of IO, just to start...
>>
>> We're working on it...
>>
>> https://github.com/schveiguy/iopipe
>> https://github.com/MartinNowak/io
>>
> 
> I was exactly referring to that two... they are great, and I've used both!
> Despite that, they seem stalled: any plan to go ahead in the medium term?

Slowly... Sorry, it's not my day job to improve these :)

But I am working currently on an http client using iopipe (https://github.com/schveiguy/httpiopipe) and improving/releasing the json parser that I wrote for my talk 2 years ago (https://github.com/schveiguy/jsoniopipe).

Hint: I hope to have a working REST client soon.

I also have a library that's stalled, but I have to pick it up again in order to deal with parsing using ranges (not yet published).

I think in order to make this more palatable, though, we really do need to focus on the io base with some sort of async fiber-based driver.

> Thanks for your work (and to Martin too)

You're welcome! Thanks for the kind words. It's actually one of the more fun projects I have worked on.

-Steve

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0

> Now as to the talk, as you could imagine, it touches on another

Somebody on the C++ side has written a reply....

https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/

Although looking at the implementation of std::conditional in the type_traits header makes me sad...

I would love to see the whole checkedint thing in C++ side by side with the d code (and generated -Os object code).

Conversely I'd love to see a Rust implementation too :-)

Given that I have probably written a lot more C++ code in my life than d...

...I do find it remarkable that I can read the d code quite easily without reaching for the reference manual, but to make sense of his C++, it sends me trawling around cppreference.com

I find Andrei's claim that checkint with a void hook reverts to int is amazing, and would love to verify that at the assembly level for both the C++ and d implementations.

On Wed, Jan 16, 2019 at 11:43:19PM +0000, John Carter via Digitalmars-d-announce wrote: [...]
> Given that I have probably written a lot more C++ code in my life than d...
> 
> ...I do find it remarkable that I can read the d code quite easily without reaching for the reference manual, but to make sense of his C++, it sends me trawling around cppreference.com

Yes, that's one of the outstanding qualities of D, and one that I was immensely impressed with when I perused the Phobos source code for the first time.  After having (tried to) read glibc's source code (if you never have, I advise you not to unless you're a jaded, hardened, hardcore C professional -- it's *not* for the faint of heart), it was like a breath of fresh air.  D does have its warts and dark corners, but I think on the readability front it has scored a home run compared to the equivalent C/C++ code.


> I find Andrei's claim that checkint with a void hook reverts to int is amazing, and would love to verify that at the assembly level for both the C++ and d implementations.

This is actually quite trivial in D.  I'm too lazy to actually check the checkedint source code, but I'd surmise it's something as simple as:

	template CheckedInt(alias hook) {
		static if (is(typeof(hook) == void))
			alias CheckedInt = int;
		else {
			struct CheckedInt {
				... // actual CheckedInt implementation here
			}
		}
	}

or something along these lines.  Standard D practice.  (I daren't even try to imagine what I'd have to do to make this work in C++. After having worked with C++ for about 2 decades or so, I don't have many good things to say about it, nor do I expect very much from it anymore.)


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.

On 1/16/2019 3:43 PM, John Carter wrote:
> Somebody on the C++ side has written a reply....
> 
> https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/

From the article:

D (with corrections):

  static if (maxLength < 0xFFFE) {
    alias CellIdx = uint16_t;
  } else {
    alias CellIdx = uint32_t;
  }

C++:

  static constexpr auto get_type() {
    if constexpr (maxLength < 0xFFFE) {
        return type<uint16_t>;
    } else {
        return type<uint32_t>;
    }
  }

  using CellIdx = decltype(get_type())::type;

1. you've got to write a function separately for every declaration you want to declare in a conditional. Imagine doing 4 or 5 of these.

2. imagine this:

    static if (condition)
      int x;
    ...
    static if (condition)
      ++x;

The C++ idiom would require (along with creating another function) creating a dummy x declaration for the (omitted) else branch of the static if.
Doable, but ugly. It kinda reminds me of the C diehards who showed you can write virtual function dispatch in C.

It's remarkable that these things can be done in C++, but the amount of "noise" and "boilerplate" in the solutions make them pretty hard to read.

On 1/16/2019 4:19 PM, H. S. Teoh wrote:
> On Wed, Jan 16, 2019 at 11:43:19PM +0000, John Carter via Digitalmars-d-announce wrote:
>> ...I do find it remarkable that I can read the d code quite easily
>> without reaching for the reference manual, but to make sense of his
>> C++, it sends me trawling around cppreference.com
> 
> Yes, that's one of the outstanding qualities of D, and one that I was
> immensely impressed with when I perused the Phobos source code for the
> first time.
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 written using C++ template metaprogramming.

The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-)

Since I mention Bartosz, I should link to his blog:

https://bartoszmilewski.com/

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 written using C++ template metaprogramming.
>
> The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-)
>
> Since I mention Bartosz, I should link to his blog:
>
> https://bartoszmilewski.com/

It was an article on Bartosz's blog where I first found out about D. I think this was the first one:

"The more things change, the more we need “immutable”"
https://bartoszmilewski.com/2009/01/