On 12/20/2023 3:19 AM, duckchess wrote:
> no, you took the examples while completely misunderstanding what the specification actually said, and then argued a strawman with those examples.

Then the specification was unclear.

On 12/20/2023 5:33 AM, jmh530 wrote:
> I agree its not a showstopper problem, but it is a marketing problem for importC.

I agree with your assessment. I don't like the current state, either.

On 12/20/2023 7:17 AM, Richard (Rikki) Andrew Cattermole wrote:
> It was ported mechanically from C++.

The front end was ported mechanically by Daniel Murphy.

The backend was ported manually by myself. It turned out to be much less work than I anticipated.

On 12/19/2023 8:28 AM, Guillaume Piolat wrote:
> In absence of new evidence, we should assume nothing makes as much difference as open-source libraries. The same paper says that the language features matter less so. So it's not very moving when people talk about languages or stdlib features on these forums, understandably the focus as a language community, but still.

This is the motivation behind ImportC - be able to use existing C libraries.

On 12/19/2023 6:15 PM, Steven Schveighoffer wrote:
> On Tuesday, 19 December 2023 at 18:37:47 UTC, H. S. Teoh wrote:
>> I'm a heavy Phobos user, and std.algorithm / std.range are among the best parts of Phobos.  Among the better modules are std.datetime, std.path, std.bigint, std.regex (I'm a regex addict). std.process is awesomely convenient for dealing with processes; one of the better-designed APIs in Phobos IMO. std.math / std.numeric are pretty standard, with a few nice things in there, though there's that strangeness with real vs. double. std.stdio is also pretty standard, but could be improved (replace with I/O pipes?). I'm addicted to std.format for its convenience but the implementation really could use some improvement, same goes for std.conv. std.uni's implementation could also use some improvement, but what's there is pretty serviceable for dealing with Unicode (main missing features: Unicode line-breaking algorithm and grapheme width -- I have an incomplete implementation of the latter but never got around to finishing it).
>>
>> std.meta / std.traits / std.typecons are good for metaprogramming, though there are some weird bits.
>>
>> Other parts of Phobos are meh, like std.container (I use it from time to
>> time but the API is klunky and rough around the edges), std.digest
>> (never used it, kinda random why it's in Phobos), std.encoding (hardly
>> ever use it), std.experimental (when it is coming out of deep freeze?),
>> std.json (meh), std.xml (bleh).  std.getopt gets the job done, but has
>> weird differences with standard Posix getopt() for no good reason, which
>> made me write my own getopt on at least 3 separate occasions.
>> std.signals - never used it, std.socket (meh), std.bitmanip (sometimes
>> useful), std.base64 (kinda random, used it once or twice but that's
>> about it -- honestly could just go in a dub library), std.csv (meh - my
>> fastcsv alternative runs way faster, though with no validation).
>> std.net.curl - weird API, std.net.isemail - seems like a totally random
>> thing to put in Phobos.  A lot of this stuff honestly could do better as
>> dub packages / external repos.
> 
> A great list and analysis!

Yes, I agree. It sounds like some of the work you've done would be candidates for Phobos3. Check with Adam Wilson!

On Wednesday, 20 December 2023 at 19:07:06 UTC, Walter Bright wrote:
> On 12/20/2023 3:19 AM, duckchess wrote:
>> no, you took the examples while completely misunderstanding what the specification actually said, and then argued a strawman with those examples.
>
> Then the specification was unclear.

It really was not unclear. but you are missing the point here.
it doesn't matter if it was or wasn't unclear, we are losing contributors because of this whole attitude.
there an implementation now so you cannot misunderstand it. people are running their own compiler fork because it's too much pain to get anything into dmd.
and you refuse to just look at the implementation and insist on having a specification again, but people are doing this in their free time, and are annoyed their work is constantly getting dismissed.

that'S why i said, if you really want to insist on a spec getting written, please just go and ask the D language foundation to pay adam to write one. or we will just again lose all the good work and probably more contributors.

we need a change to attract contributors.

On Thursday, 21 December 2023 at 10:59:29 UTC, DrDread wrote:
> On Wednesday, 20 December 2023 at 19:07:06 UTC, Walter Bright wrote:
>> On 12/20/2023 3:19 AM, duckchess wrote:
>>> no, you took the examples while completely misunderstanding what the specification actually said, and then argued a strawman with those examples.
>>
>> Then the specification was unclear.
>
> It really was not unclear. but you are missing the point here.
> it doesn't matter if it was or wasn't unclear, we are losing contributors because of this whole attitude.
> there an implementation now so you cannot misunderstand it. people are running their own compiler fork because it's too much pain to get anything into dmd.
> and you refuse to just look at the implementation and insist on having a specification again, but people are doing this in their free time, and are annoyed their work is constantly getting dismissed.
>
> that'S why i said, if you really want to insist on a spec getting written, please just go and ask the D language foundation to pay adam to write one. or we will just again lose all the good work and probably more contributors.
>
> we need a change to attract contributors.

Alright, this is getting out of hand. Walter asked for a spec so he could fully grasp the implementation, and Adam refused to write it. Atila volunteered to do so. He explained he was going on vacation for a few weeks and would get to it when he got back. He got back, got caught up on work, and has since been working to write the spec from Adam's implementation.

This is in spite of our policy right now to focus on stabilization and bug fixes rather than new features. Moreover, Atila has prioritized this over the editions document, so that's going to be delayed because of it.

So, let's be clear, Adam isn't being ignored here. Walter is going to review the spec once Atila finishes it. And then he will make a decision on it.

I'm sorry that Adam feels it isn't happening fast enough, but his string interpolation implementation is not the only thing that needs attention right now. It's going to get a fair shake, even if it doesn't happen as quickly as he or anyone else would like.

On Wednesday, 20 December 2023 at 19:51:07 UTC, Walter Bright wrote:
>
> This is the motivation behind ImportC - be able to use existing C libraries.

Yes it's a great development. https://postimg.cc/CnxQ7Mq5

My point is that we spend so much time using and translating C libraries because they have desirable characteristics that the STL-style D (and C++) libraries lacks.