On Wednesday, 21 December 2022 at 20:44:06 UTC, Walter Bright wrote:
> On 12/21/2022 12:25 PM, Don Allen wrote:
>> Again, I thought the intent of ImportC was to facilitate access to useful existing  C libraries. If the C community doesn't have an instant epiphany and adopt your position of making a distinction between arrays and pointers because you added that feature to ImportC, then your effort is going to be greeted with the sound of one hand clapping.
>
> I have some experience implementing things that no sane person wants, and it becoming a game changer. Of course, I can't know this in advance. But I'm not afraid to try.
>
>
>> I think it would be much better if you argued for your proposed change to C to the C-powers-that-be and devoted your ImportC efforts to extending its coverage of existing C dialects. I think *that* would be the best way to make ImportC a big win for D.
> I agree with you on the importance of improving ImportC's abilities to handle common .h files with their wacky use of C extensions. I just did another improvement for that a couple days ago.

Well, you are the key guy on this project. If I were in your shoes, I'd be prioritizing my todo list in descending order of your best guess of expected value to the project. My guess  of the expected value of [..] is epsilon, which is approaching zero. But it's your project, so you do what you want. But you did ask us, and that's my opinion.

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:
> 3. Help get [..] into the C Standard which will help D, too, by making D easier to interface with C
>
> 4. Getting it into C means better C debugger support for D

For the record: a feature very similar to [..] was proposed for inclusion into C23, by Martin Uecker in section 3.4 of the paper "Improved Bounds Checking for Array Types" [1]. The paper was discussed at the June 2021 meeting of the C committee [2], and in that discussion, section 3.4 received the following comment:

> With regard to section 3.4, VLA's already store sizes because the platform
> needs the size for arithmetic/subtraction. So you do not need new syntax.

I.e., the use-case of having runtime bounds information available for arrays is already covered by using a pointer-to-VLA, which (unlike VLAs themselves) are a required feature of C23 [3]. For example, one can write:

    void my_func(size_t n, int (*arr)[n])

...and then use sizeof to compute the length at runtime:

    for (size_t i = 0; i < (sizeof arr / sizeof arr[0]); i++)

Of course, anyone who has used a language like D with real slices will understand that this is a poor substitute, but convincing the C committee of that may be an uphill battle.

[1] https://open-std.org/jtc1/sc22/wg14/www/docs/n2660.pdf
[2] https://open-std.org/jtc1/sc22/wg14/www/docs/n2802.pdf
[3] https://open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

On Wednesday, 21 December 2022 at 21:14:24 UTC, Adam D Ruppe wrote:
> On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:
>> But to address your point, ImportC has been a big success for D.
>
> How did you determine this?

Number of positive Hacker News comments, perhaps? :)

On 12/21/2022 1:14 PM, Adam D Ruppe wrote:
> have had (predictable) trouble with it.
I appreciate any help identifying specific problems and reporting them on bugzilla.

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

If you are finding d too unwieldy to add features to, maybe its time to start planning d3 and how you going to clean up the technical debt

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?


Nope. I really doubt people nowadays are going to create new big projects using C. Still, I doubt even more people are going to use non standard C to create other kind of code. When importC works, I wished to see something done about what divided the D community called "betterC"

On 22/12/2022 1:22 PM, Hipreme wrote:
> I wished to see something done about what divided the D community called "betterC"

Kinda waiting on DLL support on Windows to start breaking -betterC flag up into its constituent flags.

Right now if we did it, it would break the world with no ability to go back from it :/

On 12/21/2022 11:35 AM, Steven Schveighoffer wrote:
> Stop trying to fix C. Fix D instead.

[..] is edging ahead in the twitter poll!

On Thu, Dec 22, 2022 at 12:22:18AM +0000, Hipreme via Digitalmars-d wrote: [...]
> Nope. I really doubt people nowadays are going to create new big projects using C.
[...]

You'll be surprised. I'm being paid to work on very large C projects every day, and my employer is regularly introducing new product lines following the same model (i.e., large projects heavily focused on C). And by "very large" I'm talking about millions of lines of code with complex interacting subsystems, each of which may in itself be a large C sub-project.

Much as we all wish C will see its sunset soon, it's still going to be sticking around for a good long time before it buckles under its own weight.


T

-- 
Computers shouldn't beep through the keyhole.