On 03/11/2018 11:31 PM, Laeeth Isharc wrote:
> 
> C# slices look great.

I wonder if that might open the door for D on the CLR. I know that was attempted once a long way back, but was deemed infeasible and abandoned. IIRC, inability to implement slices was the main blocker.

On Tuesday, 13 March 2018 at 23:20:22 UTC, Nick Sabalausky (Abscissa) wrote:
> On 03/11/2018 11:31 PM, Laeeth Isharc wrote:
>> 
>> C# slices look great.
>
> I wonder if that might open the door for D on the CLR. I know that was attempted once a long way back, but was deemed infeasible and abandoned. IIRC, inability to implement slices was the main blocker.

I doubt that this was the blocker because C# had ArraySegment<T> since .net framework 2.0 (2006), which is exactly a slice, but doesn't have the syntactic sugar for it.

The current C# proposal introduces a syntactic sugar similar to D (using ":" instead of "..") and extends the concept to stack arrays, because ArraySegment was limited to managed arrays.

As I remember one of the main blockers was in fact the module system which does not map to the namespace concept in C#

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky (Abscissa) wrote:
> First of all, betterC is about far more than interfacing with C. In fact, interop with C isn't really what betterC is about at all - that's a separate aspect of the language. (And those C/C++ users who still haven't come to D - for many of them the holdout is *because* of the issues betterC aims to address.

What is that issue? Runtime? It can be solved with minimal runtime that one can write in an evening, compare it to betterC effort that has no end in sight.

> Make no mistake, for all the stockholm syndrome in the C and C++ worlds, there *are* a lot people openly wanting to jump ship but don't have a sufficient option yet.

I'm afraid a sufficient option for them is proper C++ superset, betterC is only the first excuse, but not last.

> Personally, better DLL support have little to no impact on me. Obviously it does for you, and I sympathise.

FWIW DLL support was always good enough for me.

On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:
> On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky (Abscissa) wrote:
>> First of all, betterC is about far more than interfacing with C. In fact, interop with C isn't really what betterC is about at all - that's a separate aspect of the language. (And those C/C++ users who still haven't come to D - for many of them the holdout is *because* of the issues betterC aims to address.
>
> What is that issue? Runtime? It can be solved with minimal runtime that one can write in an evening, compare it to betterC effort that has no end in sight.
>
>> Make no mistake, for all the stockholm syndrome in the C and C++ worlds, there *are* a lot people openly wanting to jump ship but don't have a sufficient option yet.
>
> I'm afraid a sufficient option for them is proper C++ superset, betterC is only the first excuse, but not last.
>
>> Personally, better DLL support have little to no impact on me. Obviously it does for you, and I sympathise.
>
> FWIW DLL support was always good enough for me.

indeed, fixing DLL support (eg on OSX, where they're broken) is arguably more important (and less effort, given the larger scope of betterC) than betterC, as you can integrate D and C (or C++) projects via DLL's.
Whereas betterC does solve integrating C/C++ with D (eg requires C++ code to be ported to D which betterC doesn't magically do)

On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:
> On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky (Abscissa) wrote:
>> First of all, betterC is about far more than interfacing with C. In fact, interop with C isn't really what betterC is about at all - that's a separate aspect of the language. (And those C/C++ users who still haven't come to D - for many of them the holdout is *because* of the issues betterC aims to address.
>
> What is that issue? Runtime? It can be solved with minimal runtime that one can write in an evening, compare it to betterC effort that has no end in sight.
>
>> Make no mistake, for all the stockholm syndrome in the C and C++ worlds, there *are* a lot people openly wanting to jump ship but don't have a sufficient option yet.
>
> I'm afraid a sufficient option for them is proper C++ superset, betterC is only the first excuse, but not last.
>
>> Personally, better DLL support have little to no impact on me. Obviously it does for you, and I sympathise.
>
> FWIW DLL support was always good enough for me.

It is much more than runtime or no runtime.

First of all, that goal (better interoperability) has been on the foundation priority list for several years, it is about time to "finish it up".

You have to remember that the really big first client of betterC(++) was DMD, porting DMD from C++ was a big undertaking. Right now both DMD and LDC use a form of betterC, so it is critical to have it finalized.

Second, it is a really good tool for validating a constraint environment, running D code with minimal runtime and compiler guarantees is very good thing to have in a system level programming language.

Third, since it was introduced, it really helped better abstracting compiler internals and removing dependencies between compiler and runtime. People don't solve problems they don't have, hence introducing a new restriction added some stress that shaped a better version of D. As stated, D is a *system level programming language*, this means that ultimately needs to offer tools for embedded developers and OS kernel driver writers. betterC is one of those tools, and ultimately is part of the philosophy of pay-as-you-go, or a driving force to be better at it. Also, I think it fits nicely into "turtles all the way down" approach, as it makes the language orthogonal and more glued together vs. offering some vague advice on how to approach constraint systems, it provides rules and methods of enforcement.

Lastly, the objective is a bit vague - there is no scope attached to it, maybe this needs clarifications. Even if it means fixing all the logged bugs related to it, it is a great step, at least for me.

On Monday, 12 March 2018 at 03:31:36 UTC, Laeeth Isharc wrote:
> C# slices look great.

Dunno, when I wanted a slice in C#, I wrote a prettier one. C# could get stuff done 20 years ago already, ugly slices and native compilation won't add anything to it.

> If Phobos looks like a mess to C# programmers, so much the worse for C# programmers.

No, FWIW phobos uses more or less the same programming solutions as .net framework, the claim that they are different is an uninformed opinion.

On Thursday, 15 March 2018 at 12:23:19 UTC, Kagamin wrote:
>
> No, FWIW phobos uses more or less the same programming solutions as .net framework, the claim that they are different is an uninformed opinion.

Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
> My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly.

I do write a commerical project in C#. But I have an opposite feeling: The day D will easily compile to Javascript and be able to fully interface with it, my wish to use C# will drop pretty much instantly. I'm not even sure I would choose C# over -BetterC D!

It can already compile to Javascript using LDC/Emscripten, which is impressive, but you cannot interface with its strings and classes without glue code, except perhaps with some trickery. I have already tried doing some but so far for no avail.

And that's not to say that C# would be a bad language. I didn't hesistate to pick it over writing Javascript directly, and I don't think Java or Python would be superior for my tastes either. But it still isn't even a close match against D.

First, C# feels like it's hiding details from me, it kind of wants to maintain an ivory tower illusion. It's very hard, if possible at all, to control memory management. Libraries often feel like they're dependant on IDE (Visual Studio), not just the language.

Second, iterating in C# feels last-century standard. I like LINQ, but it still is like Phobos with only forward ranges, strange names and no thought put on avoiding needless heap allocations. And it's foreach loop can't iterate by ref, which means I often tend to iterate as if I was using C.

Third, expressive power suffers alot from lack of powerful templates, Voldemort types and var keyword being much more constrained in use than auto.

On Thursday, 15 March 2018 at 17:17:47 UTC, Dukc wrote:
> On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
>> My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly.
>
> I do write a commerical project in C#. But I have an opposite feeling: The day D will easily compile to Javascript and be able to fully interface with it, my wish to use C# will drop pretty much instantly. I'm not even sure I would choose C# over -BetterC D!
>
> It can already compile to Javascript using LDC/Emscripten, which is impressive, but you cannot interface with its strings and classes without glue code, except perhaps with some trickery. I have already tried doing some but so far for no avail.
>
> And that's not to say that C# would be a bad language. I didn't hesistate to pick it over writing Javascript directly, and I don't think Java or Python would be superior for my tastes either. But it still isn't even a close match against D.
>
> First, C# feels like it's hiding details from me, it kind of wants to maintain an ivory tower illusion. It's very hard, if possible at all, to control memory management. Libraries often feel like they're dependant on IDE (Visual Studio), not just the language.
>
> Second, iterating in C# feels last-century standard. I like LINQ, but it still is like Phobos with only forward ranges, strange names and no thought put on avoiding needless heap allocations. And it's foreach loop can't iterate by ref, which means I often tend to iterate as if I was using C.
>
> Third, expressive power suffers alot from lack of powerful templates, Voldemort types and var keyword being much more constrained in use than auto.

My quote is out of context. Somebody asked surprised why C# developers are interested in D. For me (mainly a C# developer), this is the main reason: native compilation (and this includes memory management). I highlighted the fact that the C# team keep implementing D specific ideas in each new version, so don't be surprised if your list of D exclusive features becomes smaller with each new C# iteration. My complaint was the fact that D drops features or push them into library solutions.

On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:

> I doubt that this was the blocker because C# had ArraySegment<T> since .net framework 2.0 (2006), which is exactly a slice, but doesn't have the syntactic sugar for it.

If it doesn't have the syntactic sugar how is it "exactly a slice"?

>
> The current C# proposal introduces a syntactic sugar similar to D (using ":" instead of "..") and extends the concept to stack arrays, because ArraySegment was limited to managed arrays.

If it's limited to managed arrays how is it "exactly a slice"?

Please stop repeating this fallacy, I have already corrected you once in another thread where you made the same claim about ArraySegment. I am also a C# developer and I can assure you that ArraySegment<T> has very little in common with a D slice.
It is a segment of an array of type T only! That's it!
You can't construct it from stack, static, native, memory-mapped or any other memory, and you can't coerce the type. Because it doesn't have the 'syntactic sugar' it is unusable for all practical purposes!