On Thu, 2017-06-22 at 18:38 +, Boris-Barboris via Digitalmars-d-
learn wrote:
> […]
>
> Casts are part of the type system. Yes, D type system allows
> invalid operations. It's not the compiler's fault, it's type
> system's fault.
> […]
Well maybe casts should be allowed as they effectively
On 06/22/2017 08:38 PM, Boris-Barboris wrote:
Casts are part of the type system. Yes, D type system allows invalid
operations. It's not the compiler's fault, it's type system's fault.
unittest
{
immutable int a = 4;
int* b = cast(int*) &a;
*b = 5;
assert(*(&a) == 5);
as
On Thursday, 22 June 2017 at 19:11:19 UTC, Cym13 wrote:
Here it's the programmer's fault really. You should never use
casts in normal code, cast is the ultimate switch to say "Look,
I know what I'm doing, so disable all safety, don't try to make
sense of it, and let me do my thing. If I'm telli
On Thursday, 22 June 2017 at 18:38:59 UTC, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an inval
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an invalid
operation, but the compiler is not expected to catch that for
On 6/21/17 1:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it sees
something that *mig
On 06/22/2017 12:34 PM, Boris-Barboris wrote:
Everything the language allows to compile is allowed by it's type
system, or is a bug in the compiler.
No. D is not supposed to be completely verifiable by the compiler.
For example, the type system guarantees that immutable data never
changes. Bu
On Thursday, 22 June 2017 at 09:45:09 UTC, Russel Winder wrote:
I think the term "systems programming language" contains no
actual data, so needs to be retired. In this situation it
provides no reason for conservative garbage collection.
It means the intent of language designer to let you writ
On Wed, 2017-06-21 at 10:23 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
>
> The reason the GC must be conservative is because (1) D is a systems
> programming language, and also because (2) D interfaces directly with
> C.
I think the term "systems programming language" contains no actu
On Wednesday, 21 June 2017 at 17:11:41 UTC, TheGag96 wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
S
On 06/21/2017 07:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
Being a systems programming language means you should be able to do
things outside the type system (in @system code, of course, not in @safe
code), including storing pointers as int values. Any C code that your D
program interoper
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
> On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
> > This comes from the fact that D's GC is conservative - if it sees
> > something that *might* be a pointer, it assumes it *is* a pointer
> > and t
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
So is the GC then simply made to be "better-safe-than-sorry" o
On Wednesday, 21 June 2017 at 15:34:15 UTC, TheGag96 wrote:
Could it ever be fixed?
Easiest: stick `-m64` in your build. While it is somewhat common
in 32 bit, it is very rare in 64 bit.
This comes from the fact that D's GC is conservative - if it sees
something that *might* be a pointer, i
I saw this Tip of the Week a while ago
(http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind
of perplexed at it. It seems like a crazy potential bug... How
exactly is the GC implemented that causes this problem to crop
up? Does the GC just blindly scan memory until it finds pointers
15 matches
Mail list logo
