On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:
> 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 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.

I like this and I also think providing compiler switches (ie. without naming the subset) as being acceptable.

However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches?

Only through manual compile/linking?

On Wednesday, 12 February 2014 at 04:52:00 UTC, Andrei Alexandrescu wrote:
>
> Well that should raise a question about the proper priorities.
>

My hope would be this would trickle down to GDC and I can use that.

>> 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..."
>

"I only try 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.
>

I'm not planning to stop working on the self-hosting compiler, just working on the same thing constantly gets a bit boring eventually, and half the time I'm blocked waiting for Walter to approve something anyway. (Not currently!)

As for the others, I implemented most of @safe, and I don't really care about the rest.

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

The thing is, we do almost have it, because it's not a huge thing to implement.  Low hanging fruit vs long-term priorities.

On Tuesday, 11 February 2014 at 21:19:36 UTC, Walter Bright wrote:
> On 2/11/2014 1:00 PM, Brian Rogoff wrote:
>> Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this
>> D subset?
>
> All of them.

And would all of D features be available at compile time?
CTFE/string mixins seem to be rather limited if features relying
on the GC are excluded.

"Nicolas Sicard"  wrote in message news:pvmgtktejwykqpibzvjc@forum.dlang.org...
>>> Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this
>>> D subset?
>>
>> All of them.
>
>And would all of D features be available at compile time?
>CTFE/string mixins seem to be rather limited if features relying
>on the GC are excluded.

Yes.  The limits would only apply to things used at runtime. 

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
>
> 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.
>

Why would a working phobos prevent bringing D to a new platform.  Did you mean the "D Runtime"?

Mike

El 11/02/14 20:43, Walter Bright ha escrit:
> (First off, I hate the name "better C", any suggestions?)

DonC

-- 
Jordi Sayol

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 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.
as compiler switch I would call it according to what it does:

-noPhobos

The language itself shouldn't use a different name, if you need to refer to it, I'd suggest to call it "d" (small D).

I find the idea intriguing - it could be useful pretty much everywhere where still C is in use despite C++ exists for more than two decades, not to mention other languages.

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 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?)

-DinC (= D Inc.)
-bareD
-Dwalk (as opposed to D run(time)) ouch!

(Disclaimer: I haven't read all comments, the names might already have been suggested)


> What do you think?

I like the idea.

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> (First off, I hate the name "better C", any suggestions?)

Too bad C+ is already taken.

> What do you think?

Good idea, but I'm afraid that a new phobos-like library will born. We have a better C with a old-style stdc library? I don't think I'm going to use "C+" with printf(), fopen(), fclose() and their old code style and syntax and I'll finish writing some wrappers over them using the d-power.

Probably that's good for platform like arduino where c std library is not used...

Or maybe we should provide some basic wrappers over stdc library using d-style.

On 12 February 2014 16:11, eles <eles@eles.com> wrote:

> On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:
>
>> 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 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.
>>
>
> I like this and I also think providing compiler switches (ie. without naming the subset) as being acceptable.
>
> However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches?
>
> Only through manual compile/linking?
>

Yes, exactly as with C++ today. It shouldn't be an unfamiliar problem to most.