"Walter Bright"  wrote in message news:lddug4$jgv$1@digitalmars.com...

> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>
> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.

Yeah, this has been on my todo list for a long time, last time it came up it resulting in this: https://github.com/yebblies/dmd/tree/microd

I would love to use this at work, although of course dmd does not support any of the architectures I need.

For all the people crying about forking the language, this will only fork the language as much as @safe did (ie not at all). 

On Tue, 11 Feb 2014 18:40:08 -0800, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Adam Wilson"  wrote in message news:op.xa44tcvr707hn8@invictus.hra.local...
>
>> IIRC every class, if it inherits from nothing else, inherits from Object. The compiler expects Object on all classes. Beyond that I can't speak to how dependent the compiler is on the inheritance to make classes work.
>
> extern(C++) classes do not depend on object/Object or anything else.

Awesome, I didn't know that. Does that mean we could add a switch for default linkage? That's good to know for reasons related to a couple of my D projects.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

"Adam Wilson"  wrote in message news:op.xa5d17y1707hn8@invictus.hra.local...

> Awesome, I didn't know that. Does that mean we could add a switch for default linkage? That's good to know for reasons related to a couple of my D projects.

It could be done, although I'm not sure it's a good idea. 

On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Adam Wilson"  wrote in message news:op.xa5d17y1707hn8@invictus.hra.local...
>
>> Awesome, I didn't know that. Does that mean we could add a switch for default linkage? That's good to know for reasons related to a couple of my D projects.
>
> It could be done, although I'm not sure it's a good idea.

Why?

Well, I was asking for the D-Core folks, if they could default the linkage to C++ then they could use classes without Object. And setting the default linkage might be useful for bindings.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 12 February 2014 12:55, Adam Wilson <flyboynw@gmail.com> wrote:

> On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy < yebbliesnospam@gmail.com> wrote:
>
>  "Adam Wilson"  wrote in message news:op.xa5d17y1707hn8@
>> invictus.hra.local...
>>
>>  Awesome, I didn't know that. Does that mean we could add a switch for
>>> default linkage? That's good to know for reasons related to a couple of my D projects.
>>>
>>
>> It could be done, although I'm not sure it's a good idea.
>>
>
> Why?
>
> Well, I was asking for the D-Core folks, if they could default the linkage to C++ then they could use classes without Object. And setting the default linkage might be useful for bindings.


It'll create linking problems if different modules refer to eachother, but
happen to be compiled with different flags.
It would be better to use 'extern(C):' at the top of your module, then
modules importing your module know what to expect.

extern(C++) classes are still GC allocated, so it's still not so simple. You'd need to start using emplace with manual allocation.

On 12 February 2014 12:11, Manu <turkeyman@gmail.com> wrote:

> On 12 February 2014 05:43, Walter Bright <newshound2@digitalmars.com>wrote:
>
>> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>>
>> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.
>>
>> (First off, I hate the name "better C", any suggestions?)
>>
>
> D-- ;)
>
> The subset would disallow use of any features that rely on:
>>
>> 1. moduleinfo
>> 2. exception handling
>> 3. gc
>> 4. Object
>>
>> I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos.
>>
>> What do you think?
>>
>
> It's only of interest to me in the sense that D might be able to
> infiltrate existing C codebases. And in practical reality, I just don't see
> that happening regardless.
> Most C codebases I have come in contact with are still C codebases because
> they require access to an immense number of target platforms/compilers, and
> D-- would never be able to integrate with all those targets, which means
> use of D-- alongside C would interfere with the portability of the original
> code.
>
> Personally, I don't want D--, I want D.
> I may use D-- on a microprocessor or something, it could find a good home
> there. But wouldn't it be better to just focus on the ability for D to
> link-strip any code relating to those features you list above if it turns
> out that they aren't referenced at all by the app? D should be able to
> properly eliminate everything that's not actually used by the app.
> I guess the flag is still useful to catch errors where a user attempting
> to avoid those items hits one by mistake.
>

I've changed my mind. Depending on a functional link-stripper sucks.
I think it's definitely useful, although I think it should be implemented
as a suite of flags, not just a single one. Sure, a convenience flag can be
offered, but as an implementation detail, it should be a suite of flags.

"Adam Wilson"  wrote in message news:op.xa5eelqr707hn8@invictus.hra.local...

> Why?
>
> Well, I was asking for the D-Core folks, if they could default the linkage to C++ then they could use classes without Object. And setting the default linkage might be useful for bindings.

Problems with overloading, separate compilation, some types can't be used with extern(C++) functions etc.

Just putting extern(C++): at the top of the file does a similar thing within the current system. 

On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:
> On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:
>
> I think the transition to D in the embedded world would be quicker if it were possible to obtain a minimal D language that produces the smallest binaries possible.
>

How about a 56 byte hello world [1].  Small binaries are already possible with GDC (and maybe LDC too).  If you want structs and static classes, you only need a 20 line object.d file for GDC [2].  This is proving to be quite a suitable replacement for C in my current experiments.

Mike

[1] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World!
[2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d

On 2/11/14, 6:47 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:lddug4$jgv$1@digitalmars.com...
>
>> I've toyed with this idea for a while, and wondered what the interest
>> there is in something like this.
>>
>> The idea is to be able to use a subset of D that does not require any
>> of druntime or phobos - it can be linked merely with the C standard
>> library. To that end, there'd be a compiler switch (-betterC) which
>> would enforce the subset.
>
> Yeah, this has been on my todo list for a long time, last time it came
> up it resulting in this: https://github.com/yebblies/dmd/tree/microd
>
> I would love to use this at work, although of course dmd does not
> support any of the architectures I need.

Well that should raise a question about the proper priorities.

> For all the people crying about forking the language, this will only
> fork the language as much as @safe did (ie not at all).

As I told Walter: there's this joke that goes as follows. A guy goes to the doctor and the doctor asks "How is your sex life?" and the guy goes, "Almost every day!" "How do you mean that?" "Almost on Monday, almost on Tuesday, almost on Wednesday..."

We almost have a working @safe, we almost have good reference counting, we almost have good copy construction, we almost have a working "shared" qualifier, we almost have a solution to NonNull, we almost have complete qualifier inference, and we almost have a self-hosting compiler.

Last thing we want is to add an almost working "better C" thingamaroo to the list.


Andrei

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.

I think it should be something acceptable for mainline, but should be the pursuit of those who are going to use it to implement it (unless other things finished).

I can not speak to the usefulness of this as I don't see myself as a user, but it sounds like something which will be desired by many (but I expect their to be other blockades preventing it from being a major growth to D).