• watcher (4/4) Jul 09 2019 Cheers, everybody!
• Daniel Kozak (5/9) Jul 09 2019 I am not sure what you mean? AFAIK compiler does not use GC, just alloca...
• rikki cattermole (2/18) Jul 09 2019 The compiler does use the GC. That is what the -lowmem switch does.
• Andre Pany (19/23) Jul 09 2019 From your question it is unclear wheter you ask about the GC
• bpr (7/11) Jul 09 2019 If you want to use D as a better C, which of course includes
• t (5/9) Jul 09 2019 i guess he ment:
• evilrat (3/7) Jul 09 2019 So what's the problem with simply avoiding quite short list of
• bachmeier (5/13) Jul 10 2019 Nobody has ever chosen a language because of a feature it didn't
• Dennis (2/4) Jul 10 2019 I think D lists the removal of the C preprocessor as a plus.
• bachmeier (6/10) Jul 10 2019 That wouldn't be viewed as a good thing unless followed by a
• Paulo Pinto (4/21) Jul 11 2019 Go community seems to see it differently, threating to leave if

watcher <test aol.com> writes:

Cheers, everybody!

I was wondering when it will be possible to use the compiler 
without the gc?

Thank you

Daniel Kozak <kozzi11 gmail.com> writes:

On Tue, Jul 9, 2019 at 9:37 PM watcher via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Cheers, everybody!

 I was wondering when it will be possible to use the compiler
 without the gc?

 Thank you

I am not sure what you mean? AFAIK compiler does not use GC, just allocate
and never deallocate idiom. Or do you ask when it will be possible to write
D code without reliance on GC?

rikki cattermole <rikki cattermole.co.nz> writes:

On 10/07/2019 8:48 AM, Daniel Kozak wrote:
 
 
 On Tue, Jul 9, 2019 at 9:37 PM watcher via Digitalmars-d 
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:
 
     Cheers, everybody!
 
     I was wondering when it will be possible to use the compiler
     without the gc?
 
     Thank you
 
 
 I am not sure what you mean? AFAIK compiler does not use GC, just 
 allocate and never deallocate idiom. Or do you ask when it will be 
 possible to write D code without reliance on GC?

The compiler does use the GC. That is what the -lowmem switch does.

Andre Pany <andre s-e-a-p.de> writes:

On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you

 From your question it is unclear wheter you ask about the GC 
during application runtime or during the compilation process of 
your application.

I just assume you meant the GC during application runtime. 
Depending on your scenario it is already possible to detect and 
also avoid the GC.
But your question reminds me to the first rule of performance 
optimization: Go for readable and easy code first, optimise only 
if you can measure a performance issue.
In this context it means: very likely you never ever will face a 
performance issue due to the GC. If you really face an issue, it 
might be in 5 % of your application. D will provide you different 
tools to control or even avoid GC here.

Beside that, the GC was improved in recent DMD version (parallel 
execution) and also a fork based GC for posix system is on it's 
way.

Kind regards
Andre

bpr <brogoff gmail.com> writes:

On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you

If you want to use D as a better C, which of course includes 
omitting the GC, there is an aptly named compiler switch 
"-betterC" which leaves you with a powerful subset of D that 
still has the static metaprogramming features. For now, you don't 
have many D libraries available to you in DasBetterC.

https://dlang.org/spec/betterc.html

t <tette comcast.com> writes:

On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you

i guess he ment:
i do not want to allocate memory with the gc, but use all d 
features. the resultant executable should not include a gc. as 
far as i know, thats not possible and thats why i don't use d.

evilrat <evilrat666 gmail.com> writes:

On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. as 
 far as i know, thats not possible and thats why i don't use d.

So what's the problem with simply avoiding quite short list of 
features that may ever involve GC, and keep the GC without work?

bachmeier <no spam.net> writes:

On Wednesday, 10 July 2019 at 05:41:43 UTC, evilrat wrote:
 On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. as 
 far as i know, thats not possible and thats why i don't use d.

 So what's the problem with simply avoiding quite short list of 
 features that may ever involve GC, and keep the GC without work?

Nobody has ever chosen a language because of a feature it didn't 
have. That wouldn't make sense. You can write dismissive comments 
about a language because of features you don't like but removal 
of features will never be a reason to use a language.

Dennis <dkorpel gmail.com> writes:

On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 but removal of features will never be a reason to use a 
 language.

I think D lists the removal of the C preprocessor as a plus.

bachmeier <no spam.net> writes:

On Wednesday, 10 July 2019 at 19:29:10 UTC, Dennis wrote:
 On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 but removal of features will never be a reason to use a 
 language.

 I think D lists the removal of the C preprocessor as a plus.

That wouldn't be viewed as a good thing unless followed by a 
better way to do the same things as a preprocessor. You can't 
really say that the GC can be removed from D because there's 
something better. GC-less D doesn't bring anything new to the 
table.

Paulo Pinto <pjmlp progtools.org> writes:

On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 On Wednesday, 10 July 2019 at 05:41:43 UTC, evilrat wrote:
 On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. 
 as far as i know, thats not possible and thats why i don't 
 use d.

 So what's the problem with simply avoiding quite short list of 
 features that may ever involve GC, and keep the GC without 
 work?

 Nobody has ever chosen a language because of a feature it 
 didn't have. That wouldn't make sense. You can write dismissive 
 comments about a language because of features you don't like 
 but removal of features will never be a reason to use a 
 language.

Go community seems to see it differently, threating to leave if 
it ever improves the error handling or gets some kind of 
lightweight generics as part of the Go 2.0 ongoing transition.