On Saturday, 21 June 2014 at 10:49:57 UTC, Artur Skawina via
Digitalmars-d wrote:
It's not about being able to contribute to DMD, it is about
being able
to work on /other/ projects. If contributing to DMD carries the
risk of
affecting the latter then it's simply best to avoid it; it's
not a
On 22 June 2014 08:21, SomeDude via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 21 June 2014 at 10:49:57 UTC, Artur Skawina via
Digitalmars-d wrote:
It's not about being able to contribute to DMD, it is about being able
to work on /other/ projects. If contributing to DMD
On 06/22/14 09:48, Iain Buclaw via Digitalmars-d wrote:
And if your reasoning for not working on the front-end for GDC or LDC
is that they are behind current development. Then why don't you make
your first contribution as updating the chosen compiler to be aligned
with DMD development!
1)
On Saturday, 21 June 2014 at 10:49:57 UTC, Artur Skawina via
Digitalmars-d wrote:
In other words, what is potential danger you need to be
concerned about that makes potential contributions too risky?
One problem I am aware of is redistribution issue which is
common blocker with getting into
On 06/22/14 15:13, Dicebot via Digitalmars-d wrote:
You are passing copyright to DigitalMars for all contributions anyway, Boost
or proprietary.
Not true in general. Or are you saying that Walter requires copyright
assignment before merging code? If that would be the case then this
would be
On Sunday, 22 June 2014 at 15:01:57 UTC, Artur Skawina via
Digitalmars-d wrote:
On 06/22/14 15:13, Dicebot via Digitalmars-d wrote:
You are passing copyright to DigitalMars for all contributions
anyway, Boost or proprietary.
Not true in general. Or are you saying that Walter requires
On 6/22/2014 9:08 AM, Dicebot wrote:
All DMD source files mention Copyright (c) *** by Digital Mars. As far as I
understand that implies that any pull request that does not explicitly mentions
copyright does assignment automatically. Which totally makes sense because
source base with distributed
On Sunday, 22 June 2014 at 16:08:58 UTC, Dicebot wrote:
All DMD source files mention Copyright (c) *** by Digital
Mars. As far as I understand that implies that any pull
request that does not explicitly mentions copyright does
assignment automatically. Which totally makes sense because
source
On Sunday, 22 June 2014 at 18:47:06 UTC, Walter Bright wrote:
Copyright assignment is required in other larger projects, like
Linux and gcc.
Not Linux, no.
David
On 6/22/2014 2:02 PM, Joakim wrote:
Since Artur is being so evasive, I believe he's talking about the same reasons
why Walter purposely won't even look at llvm code, which is basically
BSD-licensed. Any time you can say you haven't even looked at any outside code,
let alone contributed to it,
On 06/20/14 23:28, Dicebot via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 11:12:46 UTC, Artur Skawina via Digitalmars-d
wrote:
That is fortunately not a problem for dmdfe, as boost/gpl should be
ok for (almost) everyone. But the cost of having to deal with another
license, for a
On Friday, 20 June 2014 at 00:15:36 UTC, Walter Bright wrote:
On 6/19/2014 12:59 PM, Joakim wrote:
I don't know enough about these copyright tainting concerns to
say if it's a
good idea, just pointing out that he was talking about the
backend, not the
frontend.
Ok, but I'll also point out
On 06/20/14 13:51, David Nadlinger via Digitalmars-d wrote:
On Friday, 20 June 2014 at 00:15:36 UTC, Walter Bright wrote:
On 6/19/2014 12:59 PM, Joakim wrote:
I don't know enough about these copyright tainting concerns to say if it's a
good idea, just pointing out that he was talking about the
On 6/20/2014 5:13 AM, Artur Skawina via Digitalmars-d wrote:
On 06/20/14 13:51, David Nadlinger via Digitalmars-d wrote:
Which wouldn't really help Artur (whether his concerns are justified or
not), as we usually tell people to contribute their frontend patches
directly to the upstream DMD
On Thursday, 19 June 2014 at 11:12:46 UTC, Artur Skawina via
Digitalmars-d wrote:
Wait what? Do you know a single person who decided to not work
on DMD FE because of kind of formally (but not practically)
non-free backend?
Well, do you think I would have said what I did if this issue
didn't
On 6/18/2014 10:18 AM, H. S. Teoh via Digitalmars-d wrote:
Everyone talks about it, but nobody does anything about it, so here goes
nothing:
https://issues.dlang.org/show_bug.cgi?id=12941
Obviously, I have no idea what should go in that list, so everyone who
cares about this issue,
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d
wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation drives away the
most valuable ones (since those will often be
On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d
wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation
On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?
No,
On Thu, Jun 19, 2014 at 06:24:59PM +, Tobias Pankrath via Digitalmars-d
wrote:
On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad wrote:
On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
Granted infinite resources. Good, now that we ruled that thing out,
can we talk
On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited,
too.
If I need to enumerate all possible program states, there will
always exists a program that can run on my box but will not be
verifiable on it (since I lack
On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
Exactly. Just because something is *finite*, doesn't
necessarily mean
it's practical. Anything that requires enumeration of all
possible
states is impractical, because it has an exponential worst case
bound,
which
On Thu, Jun 19, 2014 at 07:12:52PM +, via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via Digitalmars-d
wrote:
Exactly. Just because something is *finite*, doesn't necessarily
mean it's practical. Anything that requires enumeration of all
possible states
On Thursday, 19 June 2014 at 18:10:57 UTC, Walter Bright wrote:
On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via
Digitalmars-d wrote:
The number of potential
On Thursday, 19 June 2014 at 19:12:53 UTC, Ola Fosheim Grøstad
wrote:
You are being silly. You either discuss computability or you
discuss complexity. Please don't mix the two topics.
Do you have something to contribute to THIS discussion, or ill
you continue to bring irrelevant topic in ?
On 06/19/2014 06:06 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
...
In the real world you work with typical programs that run on finite
resources guided by heuristics. There is no proof that you cannot have
@safe.
I assume you mean @safe === memory safety.
So leave
On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
But the non-solvability of the halting problem means that there
is no
algorithm that can compress every possible program.
Even if true, programmers don't write every possible program when
they try to write @safe
On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:
I assume you mean @safe === memory safety.
I mean that the best route in general is: @safe = memory safe
features on the local level (trivial) = strength reduction
into memory safe use of memory unsafe features (trivial).
No,
On 06/19/2014 09:06 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited, too.
If I need to enumerate all possible program states, there will always
On Thu, Jun 19, 2014 at 08:31:53PM +, via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via Digitalmars-d
wrote:
But the non-solvability of the halting problem means that there is no
algorithm that can compress every possible program.
Even if true,
On Thursday, 19 June 2014 at 20:47:16 UTC, H. S. Teoh via
Digitalmars-d wrote:
programs!). So the only remaining approach is to consider all
possible
programs. Which means you have to implement exhaustive state
space
search. Which is impractical for the reasons I stated.
No. Is a program
On 06/19/2014 10:39 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:
...
No, your line of reasoning is flawed. The amount of resources is not a
constant. You must prove that memory safety holds for
I have not set
On 06/19/2014 11:28 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
But we aren't talking machine language, we are talking D.
This part is spot on.
On 6/19/2014 12:59 PM, Joakim wrote:
Admittedly his concerns are unclear, but his problem is with the backend, not
the frontend, which he already said he likes better now that it's
boost-licensed. He claims that the proprietary backend scares potential
contributors away and that it should be
On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of
programs which is memory safe which is the claim I was arguing
against,
It will single out exactly the programs that are most certainly
memory safe, and also single out
On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of
programs which is memory safe which is the claim I was arguing
against,
It will single out exactly
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not allowed and
adding to the list when new holes are discovered
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing what is not allowed
and
adding to the list when new holes are discovered
On Wednesday, 18 June 2014 at 06:50:14 UTC, deadalnix wrote:
That isn't splitting hair. You are loosing track of the big
picture here. To come back to the original problem :
memset(foo, 0, typeof(foo).sizeof);
Walter mention that this is not corrupting memory and therefore
@safe.
memset is
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing what is not
allowed and
adding to the list when new holes are discovered
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
From my perspective, it is like bug reports I'd often get for
the compiler that consisted solely of:
Your compiler doesn't work.
It's just not helpful. There's nothing I can do with that.
Lol, I'd love to see your response
On 18/06/2014 8:52 p.m., Joakim wrote:
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
From my perspective, it is like bug reports I'd often get for the
compiler that consisted solely of:
Your compiler doesn't work.
It's just not helpful. There's nothing I can do with
On Wednesday, 18 June 2014 at 09:16:32 UTC, Rikki Cattermole
wrote:
From my experience, one of the reasons I haven't had much to do
with the development of dmd is simply to compile dmd, druntime
is not as straight forward as it could be.
All I can say is with ddmd make it compilable with dub
On 06/18/14 10:14, Walter Bright via Digitalmars-d wrote:
Also, D is a collaborative effort. If there's an issue that engages your
interest, step up and help out. I simply cannot do everything. This n.g. is
full of you should do this, you should do that largely directed at me. You
guys
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright
wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not
allowed and
On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
Not really, you can prove termination for all programs with 3
instructions and 3 bytes of RAM. You can do it for all programs
with 4 instructions and 4 bytes of RAM. You can do it for all
programs with N instructions and N
On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not allowed and
adding to the list when new holes are
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via
Digitalmars-d wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation drives
away the
most valuable ones (since those will often be the ones which
treat the
legal aspects seriously and
On Wed, Jun 18, 2014 at 04:39:27PM +, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by
On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:
On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
Not really, you can prove termination for all programs with 3
instructions and 3 bytes of RAM. You can do it for all
programs with 4 instructions and 4 bytes
On Wednesday, 18 June 2014 at 19:17:50 UTC, Marc Schütz wrote:
Jumps and loops don't matter. The point is that such a program
only has a finite amount of possible states: The 4 bytes of
RAM, plus the current instruction pointer (to be 2 bits for 4
instructions). In this case, there are only
On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:
Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs)
On Wednesday, 18 June 2014 at 20:58:46 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:
Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and
On 6/18/2014 2:16 AM, Rikki Cattermole wrote:
From my experience, one of the reasons I haven't had much to do with the
development of dmd is simply to compile dmd, druntime is not as straight forward
as it could be.
You don't need to actually hack on dmd or druntime to make valuable
On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?
No, finite resources, and that is only a worst case upper bound.
It does
You have a lot of good thoughts on this issue.
You have specific problems in mind but do not identify them other than in vague
terms. I guarantee that I am really, really bad at mindreading.
Instead, I would strongly prefer that you:
1. write bugzilla issues for the problems that you
On Tuesday, 17 June 2014 at 20:25:52 UTC, Walter Bright wrote:
You have a lot of good thoughts on this issue.
You have specific problems in mind but do not identify them
other than in vague terms. I guarantee that I am really, really
bad at mindreading.
Instead, I would strongly prefer that
On 6/17/2014 1:30 PM, deadalnix wrote:
I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.
Please have a step back and look at the broader issue here.
What plan of action do you propose?
On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:
On 6/17/2014 1:30 PM, deadalnix wrote:
I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.
Please have a step back and look at
On Monday, 16 June 2014 at 13:12:33 UTC, Timon Gehr wrote:
My point was that no implementation of @safe whatsoever can
make it _equivalent_ to memory safety (i.e. @safe will never
single out precisely those programs that do not corrupt
memory). It will always only approximate memory safety.
On 6/17/2014 1:59 PM, deadalnix wrote:
On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:
What plan of action do you propose?
Make everything @system
The default is @system.
unless they are proven @safe instead of
trying to plug the holes in the condom one by one and hope you
On 6/17/2014 2:50 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Out of curiosity, what is memory safety defined to be?
http://en.wikipedia.org/wiki/Memory_safety
Does it include running out of stack?
Depends. If the stack has protection against stack overflow, then it
On 06/17/2014 11:50 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
...
Btw, Rice's theorem is based on the halting problem for TMs… so it
suffers from the same issues as everything else in theoretical CS when
it comes to practical situations.
There is no such 'issue', or
On 06/16/2014 06:49 AM, Walter Bright wrote:
On 6/15/2014 4:26 PM, Timon Gehr wrote:
On 06/16/2014 01:06 AM, Walter Bright wrote:
I don't understand your question. I don't know what is unhelpful about
saying that @safe refers to memory safety.
...
You stated the two to be equivalent earlier,
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but
not @safe does not
imply not memory safe.
@safe in D == memory safe.
What Timon is saying is that not all memory safe code
On 6/15/2014 12:44 AM, David Nadlinger wrote:
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.
@safe in D == memory safe.
What
David Nadlinger:
@safe = memory safe, but not memory safe = @safe.
Apparently that's not true, according to the post on the LLVM
blog linked here:
http://forum.dlang.org/thread/okratgxrikskmylmw...@forum.dlang.org
Bye,
bearophile
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but
not @safe does not
imply not memory safe.
@safe in D == memory safe.
Why? I found dozens of cases when @safe is broken, let
On 06/15/2014 10:33 AM, Walter Bright wrote:
What Timon is saying is that not all memory safe code is verifiably
@safe.
In D, they are defined to be the same thing,
Since when?
http://dlang.org/function
Function Safety
Safe functions are functions that are _statically checked_ to exhibit
On 6/15/2014 2:48 AM, Timon Gehr wrote:
On 06/15/2014 10:33 AM, Walter Bright wrote:
What Timon is saying is that not all memory safe code is verifiably
@safe.
In D, they are defined to be the same thing,
Since when?
http://dlang.org/function
Function Safety
Safe functions are functions
On 6/15/2014 2:30 AM, Maxim Fomin wrote:
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.
@safe in D == memory safe.
Why? I found
On 6/15/2014 2:30 AM, Maxim Fomin wrote:
I found dozens of cases when @safe is broken, let alone other issues in
bugzilla.
I have added the keyword 'safe' to bugzilla. I'd appreciate it if you would go
through the bugzilla issues you've identified with @safe, and mark them with the
'safe'
On 06/15/2014 08:44 PM, Walter Bright wrote:
On 6/15/2014 2:48 AM, Timon Gehr wrote:
On 06/15/2014 10:33 AM, Walter Bright wrote:
What Timon is saying is that not all memory safe code is verifiably
@safe.
In D, they are defined to be the same thing,
Since when?
http://dlang.org/function
On 6/15/2014 3:45 PM, Timon Gehr wrote:
I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...
Note that this is frustratingly unhelpful for deciphering your point about
memory safe = verifiably @safe by definition. Are you defining memory
On 06/16/2014 01:06 AM, Walter Bright wrote:
On 6/15/2014 3:45 PM, Timon Gehr wrote:
I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...
Note that this is frustratingly unhelpful for deciphering your point
about
memory safe = verifiably
On 6/15/2014 4:26 PM, Timon Gehr wrote:
On 06/16/2014 01:06 AM, Walter Bright wrote:
I don't understand your question. I don't know what is unhelpful about
saying that @safe refers to memory safety.
...
You stated the two to be equivalent earlier, which is impossible.
It is for Java, why
On 6/15/2014 9:49 PM, Walter Bright wrote:
No, it is not. For example, assigning an int to a pointer is a semantic issue,
not a semantic one.
Gack, I meant not a SYNTACTIC one.
On 6/11/2014 8:56 AM, Remo wrote:
This is pretty strange behavior.
At least on Windows I can not confirm this.
Visual Studio 2013, Intel Compiler and Clang for windows have the same
consistent behavior here.
private do NOT affect struct size.
But there is a parameter in Visual Studio that
On Wednesday, 11 June 2014 at 03:19:55 UTC, Walter Bright wrote:
On 6/10/2014 7:44 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright
wrote:
On 6/10/2014 5:27 PM, deadalnix wrote:
I'm talking about structs, not classes.
Ok, but since D structs do not inherit, how
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:
Hmm, this could have serious problems with the following:
S1 s1;
S2 s2;
s2.c = 3;
memcpy(s2.s1, s1, sizeof(S1)); // Oops! stomped on s2.c
Yes, that is why they do it only in specific condition (ie when
the thing use C++
On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:
Hmm, this could have serious problems with the following:
S1 s1;
S2 s2;
s2.c = 3;
memcpy(s2.s1, s1, sizeof(S1)); // Oops! stomped on s2.c
Yes, that is why they do it only in specific
On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:
On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright
wrote:
Hmm, this could have serious problems with the following:
S1 s1;
S2 s2;
s2.c = 3;
memcpy(s2.s1, s1, sizeof(S1)); // Oops!
On 6/11/2014 12:22 AM, deadalnix wrote:
On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:
On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:
Hmm, this could have serious problems with the following:
S1 s1;
S2 s2;
s2.c = 3;
On 06/11/2014 11:35 AM, Walter Bright wrote:
I'm not so sure about that, either. There are many ways of bit copying
structs, and some of them are perfectly memory safe.
It is not provable by the compiler, therefore it is not @safe.
Not memory safe implies (is supposed to imply) not @safe
On Wednesday, 11 June 2014 at 07:22:51 UTC, deadalnix wrote:
On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:
On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright
wrote:
Hmm, this could have serious problems with the following:
S1
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.
@safe in D == memory safe.
I was messing around with clang codegen and noticed that sometime
it optimize structs using the tail pad, and sometime it doesn't.
It ended up in the following stack overflow question :
deadalnix:
thought ?
I think for D there is a lower handing fruit: the D specs allow
to reorder class instance fields, but I think the D front-end is
not yet doing that.
Bye,
bearophile
On Tuesday, 10 June 2014 at 08:57:26 UTC, bearophile wrote:
deadalnix:
thought ?
I think for D there is a lower handing fruit: the D specs allow
to reorder class instance fields, but I think the D front-end
is not yet doing that.
But only for classes, not for structs.
10-Jun-2014 11:30, deadalnix пишет:
[snip]
extern(D) do tail pad optimize.
extern(C) struct do not tail pad optimize.
extern(C++) do tail pad with C++ rules:
do not tail pad if (otherwise tail pad):
1. has no non-static data members that aren't standard-layout
2. has no virtual functions and no
On 6/10/2014 12:30 AM, deadalnix wrote:
thought ?
This does not apply to D structs because D structs do not inherit.
C doesn't have classes, so no issues there.
extern(C++) class should match the C++ ABI for this.
extern(D) class we are free to innovate with the layout.
I suggest turning
On Tuesday, 10 June 2014 at 20:50:46 UTC, Walter Bright wrote:
On 6/10/2014 12:30 AM, deadalnix wrote:
thought ?
This does not apply to D structs because D structs do not
inherit.
C doesn't have classes, so no issues there.
extern(C++) class should match the C++ ABI for this.
extern(D)
On 6/10/2014 5:27 PM, deadalnix wrote:
I'm talking about structs, not classes.
Ok, but since D structs do not inherit, how does tail pad optimization apply?
On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:
On 6/10/2014 5:27 PM, deadalnix wrote:
I'm talking about structs, not classes.
Ok, but since D structs do not inherit, how does tail pad
optimization apply?
struct S1 {
int a;
byte b;
}
struct S2 {
S1 s1;
On 6/10/2014 7:44 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:
On 6/10/2014 5:27 PM, deadalnix wrote:
I'm talking about structs, not classes.
Ok, but since D structs do not inherit, how does tail pad optimization apply?
struct S1 {
int a;
On 6/10/2014 7:44 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:
On 6/10/2014 5:27 PM, deadalnix wrote:
I'm talking about structs, not classes.
Ok, but since D structs do not inherit, how does tail pad optimization apply?
struct S1 {
int a;
96 matches
Mail list logo
