Here's another thing that should be allowed that doesn't depend
on optimizations:
Any code path in a @nogc function that is guaranteed to abort the
program should be exempt from @nogc enforcement. This includes
assert(0) and throwing an Error.
Take std.exception.assumeWontThrow() as an
On 2014-04-26 16:43, Daniel Murphy wrote:
At least these days it only happens when Walter and Andrei agree instead
of just Walter merging whatever he feels like.
Yeah, but it's still a problem when the rest of the community disagrees.
--
/Jacob Carlborg
On 4/25/2014 7:28 AM, bearophile wrote:
Dicebot:
It is unacceptable to have code that fails with one compiler and works with
the other despite the shared frontend version. Such enhanced @nogc
attributes must be placed into compiler-specific attribute space and not as a
core language feature.
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
Well, @nogc is not released yet. Please tell me we don't have
to avoid breaking code based on git HEAD...
We've already done that before, with UDA's. So, you never know.
--
/Jacob Carlborg
On 2014-04-25 16:28, bearophile wrote:
This problem was underlined during this thread far before the merging of
the @nogc implementation. Why have Walter Andrei ignored the problem?
What's the point of creating a DIP if you ignore the problems found in
its discussion? What's the point of 338
Walter Bright:
The @nogc logic is entirely contained in the front end, and is
not affected by back end logic.
Thank you for your answer and sorry for me being sometimes too
much nervous.
So the problem I was alarmed about doesn't exists.
Some time ago I have filed this ER:
Jacob Carlborg wrote in message news:ljfvec$126l$1...@digitalmars.com...
That's a problem. The problem is if someone has an idea/code it wants to
be merged, it's enough to convince one developer with push right to get it
merged.
At least these days it only happens when Walter and Andrei
If I am not missing some more point, what is the best solution?
Before this question gets lost, I'd like to receive some kind of
answer.
Thank you,
bearophile
On 04/27/2014 01:32 AM, bearophile wrote:
If I am not missing some more point, what is the best solution?
Before this question gets lost, I'd like to receive some kind of answer.
Thank you,
bearophile
The front end already distinguishes dynamic and static array literals
(in a limited
Walter Bright:
Pointing out these issues is exactly what @nogc is designed to
do.
Using @nogc is like putting your code under a newly invented
microscope, it allows to see things that I missed before :-)
Bye,
bearophile
On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
immutable int x = 3;
auto result = data[].map!(y = y * x);
}
test.d(1,6): Error: function D main @nogc function allocates a
closure with the GC
Such kind of code is common, so a good amount of range-based
code can't be
On Fri, 25 Apr 2014 07:28:27 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
immutable int x = 3;
auto result = data[].map!(y = y * x);
}
test.d(1,6): Error: function D main @nogc function allocates
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may make some @nogc code valid on some
compilers, and invalid on others, even though the resulting
execution is the same.
I don't think this is a
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
It could. I don't think the compiler is smart enough, as it
would need to verify result doesn't go anywhere (flow analysis).
In that case I'd like to see recursive inlining, if it makes
stack allocations more probable.
On Friday, 25 April 2014 at 12:21:40 UTC, David Nadlinger wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may make some @nogc code valid on some
compilers, and invalid on others, even though the
On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger c...@klickverbot.at
wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
One interesting thing about this is that the compiler implementation
may make some @nogc code valid on some compilers, and invalid on
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger
c...@klickverbot.at wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may
On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
I don't know that it's desirable to have @nogc reject code even though
an allocation does not occur. I agree the situation is not ideal, but
@nogc is
Dicebot:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a core language
feature.
This problem was underlined during
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer
wrote:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
It is unacceptable to have code that fails with one compiler and works
with the other despite the shared frontend version. Such enhanced
@nogc
On Fri, 25 Apr 2014 11:29:37 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
But what really is the difference between a function that is marked
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv
Which is the very reason why I was so insisting of defining
exact set of cases when optimisation is to be guaranteed in
spec (before releasing @nogc).
On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer
wrote:
You know what, in fact, @nogc may need to be re-branded as
compiler-specific.
You should have a compiler switch that let's you get
compiler-optimal non-portable @nogc.
On Fri, 25 Apr 2014 20:50:46 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer wrote:
You know what, in fact, @nogc may need to be re-branded as
compiler-specific.
You should have a compiler switch that
On Saturday, 26 April 2014 at 04:49:07 UTC, Steven Schveighoffer
wrote:
In any case, I don't need another explanation, I don't think it
will ever make sense to me.
It makes sense because there are two different use cases:
1. Library authors who need a more conservative interpretation of
On 23/04/14 19:12, Walter Bright wrote:
Too many double negatives for me to be sure what you're saying. But it
is clear to me that with Michel's experience with ARC in iOS combined
with Manu's enthusiasm for it suggests that they are the right team to
come up with a workable proposal, where
Walter Bright:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Currently this code doesn't compile because the lambda allocates
the closure on the heap:
void main() @nogc {
import std.algorithm: map;
int[3] data = [1,
On 4/24/2014 6:35 AM, bearophile wrote:
Currently this code doesn't compile because the lambda allocates the closure on
the heap:
Pointing out these issues is exactly what @nogc is designed to do.
void main() @nogc {
import std.algorithm: map;
int[3] data = [1, 2, 3];
Walter Bright:
Pointing out these issues is exactly what @nogc is designed to
do.
Right.
Can't is a bit strong of a word. Needing a workaround that is
perhaps a bit ugly is more accurate. For your example,
enum int x = 3;
will solve the issue.
In most cases that x is a run-time
On 4/24/2014 11:49 AM, bearophile wrote:
Walter Bright:
Can't is a bit strong of a word. Needing a workaround that is perhaps a bit
ugly is more accurate. For your example,
enum int x = 3;
will solve the issue.
In most cases that x is a run-time value, as in my example.
You can make
On 23/04/14 06:33, Walter Bright wrote:
I repeatedly said that it is not memory safe because you must employ
escapes from it to get performance.
Apparently you need that for the GC as well, that's why this thread was
started to begin with.
--
/Jacob Carlborg
On 22/04/14 20:48, Steven Schveighoffer wrote:
I mean not like I can't because I don't want to or don't have time, but
can't as in I lack the skill set :) It's interesting to debate, and I
get the concepts, but I am not a CPU/cache guy, and these things are
really important to get right for
On 22 April 2014 05:03, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
Total
Manu, you obviously believe in ARC. I've made an attempt to do ARC, detailed in
the other thread here. I failed.
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
Michel Fortin also wants to bring iOS ARC to D.
I suggest you get together with Michel and work out a detailed
On 23 April 2014 04:28, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote:
Objective-C isn't memory safe because it lets you play with raw
pointers too. If you limit yourself to ARC-managed pointers
(and avoid undefined behaviours inherited from C) everything is
perfectly memory safe.
I'm not convinced
On 23/04/14 10:31, Walter Bright wrote:
Manu, you obviously believe in ARC. I've made an attempt to do ARC,
detailed in the other thread here. I failed.
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
That conversation started out from the D/Objective-C conversations. To
have
On 2014-04-23 09:50:57 +, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com said:
On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote:
Objective-C isn't memory safe because it lets you play with raw
pointers too. If you limit yourself to ARC-managed pointers (and avoid
On 2014-04-23 04:33:00 +, Walter Bright newshou...@digitalmars.com said:
On 4/22/2014 12:42 PM, Michel Fortin wrote:
On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said:
Memory safety is not a strawman. It's a critical feature for a modern
language, and will
On Wed, 23 Apr 2014 05:14:44 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 23 April 2014 04:28, Steven Schveighoffer via Digitalmars-d
ARC does not equal guaranteed memory safety. So NO, it cannot replace
the GC
for D @safe code. That doesn't make it useless.
Why
On Wed, 23 Apr 2014 02:11:38 -0400, Jacob Carlborg d...@me.com wrote:
On 22/04/14 20:48, Steven Schveighoffer wrote:
I mean not like I can't because I don't want to or don't have time, but
can't as in I lack the skill set :) It's interesting to debate, and I
get the concepts, but I am not a
On 2014-04-23 17:57, Steven Schveighoffer wrote:
Sure, but there are things I CAN do with my limited time, that I do have
the expertise for. I've already been schooled by the likes of you and
Michel Fortin on my knowledge of ref counting implementation.
That's completely different. I've felt
On 4/23/2014 6:10 AM, Jacob Carlborg wrote:
That conversation started out from the D/Objective-C conversations. To have ARC
in D and be compatible with the one in Objective-C you don't have many choices.
I'm not sure but I don't think your proposal was not compatible with ARC in
Objective-C.
On Monday, 21 April 2014 at 23:02:54 UTC, Walter Bright wrote:
There is JUST NO WAY that:
struct RefCount {
T* data;
int* count;
}
This is actually quite efficient compared to the standard
NSObject which uses a hashtable for refcounting:
On 21/04/14 19:49, Frustrated wrote:
Not quite. AST macros simply transform code. Attributes attach meta data
to code. While I'm sure there is some overlap they are not the same.
Unless AST macros have the ability to arbitrary add additional
contextual information to meta code then they can't
On 22/04/14 01:02, Walter Bright wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be
memory safe. This makes it simply not acceptable for D in the general
case. It works with iOS because iOS allows all kinds of (unsafe) ways
to escape it, and it must offer those ways
On 4/21/2014 11:51 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
This is actually quite efficient compared to the standard NSObject which uses a
hashtable for refcounting:
It's not efficient compared to pointers.
On 4/22/2014 12:11 AM, Jacob Carlborg wrote:
On 22/04/14 01:02, Walter Bright wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be
memory safe. This makes it simply not acceptable for D in the general
case. It works with iOS because iOS allows all kinds of (unsafe) ways
On Tuesday, 22 April 2014 at 09:02:21 UTC, Walter Bright wrote:
On 4/22/2014 12:11 AM, Jacob Carlborg wrote:
On 22/04/14 01:02, Walter Bright wrote:
The thing is, with iOS ARC, it cannot be statically
guaranteed to be
memory safe. This makes it simply not acceptable for D in the
general
On Tuesday, 22 April 2014 at 09:40:15 UTC, Ola Fosheim Grøstad
wrote:
if( CAS_SET_BIT(ref+32,THREADID)==THREADID ){
Make that:
if( CAS_SET_BIT(ref+32,THREADID) == (1THREADID) ){
On Tuesday, 22 April 2014 at 09:01:20 UTC, Walter Bright wrote:
On 4/21/2014 11:51 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
This is actually quite efficient compared to the standard
NSObject which uses a
hashtable for refcounting:
It's not efficient compared to
On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright
wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any
On Mon, 21 Apr 2014 17:52:30 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Here are two very good reasons to avoid extensive ref-counting:
1. transactional memory ( you don't want a lock on two reads )
2. cache coherency ( you don't want barriers everywhere )
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/21/2014 1:29 PM, Steven Schveighoffer wrote:
I think you are misunderstanding something. This is not for a pervasive
ARC-only, statically guaranteed system. The best example he gives (and
I agree
with
On Tuesday, 22 April 2014 at 13:11:55 UTC, Steven Schveighoffer
wrote:
Single threaded ARC can go a long way in D.
Not without changing language semantics/mechanisms?
We statically know whether data is shared or not.
I don't understand how you can know this when you allow foreign
On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 22 April 2014 at 13:11:55 UTC, Steven Schveighoffer wrote:
Single threaded ARC can go a long way in D.
Not without changing language semantics/mechanisms?
We statically know
On Tuesday, 22 April 2014 at 13:39:54 UTC, Steven Schveighoffer
wrote:
On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad Can you
explain this?
When you use a C/C++ framework you don't know what happens to the
pointers you hand to it.
You also don't know which threads call your
On Tue, 22 Apr 2014 09:48:28 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 22 April 2014 at 13:39:54 UTC, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad Can you explain
this?
When you use a C/C++ framework you don't
On Tuesday, 22 April 2014 at 14:07:47 UTC, Steven Schveighoffer
wrote:
know this you are required to know the internals of the
framework you are utilizing or inject runtime guards into your
D functions?
Or just mark those objects sent into the framework as shared.
Having multi-threaded RC
On Tuesday, 22 April 2014 at 06:51:40 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 21 April 2014 at 23:02:54 UTC, Walter Bright wrote:
There is JUST NO WAY that:
struct RefCount {
T* data;
int* count;
}
This is actually quite efficient compared to the standard
NSObject
On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
iOS now on 64-bit processors doesn't necessarily use a hashtable
for refcounting. Basically, only 33 bits of the 64-bit pointer
are used to actually refer to an address, then 19 of the
remaining bits are used to store an inline reference
On Tue, 22 Apr 2014 13:22:19 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
iOS now on 64-bit processors doesn't necessarily use a hashtable
for refcounting. Basically, only 33 bits of the 64-bit pointer
are used
On Tuesday, 22 April 2014 at 17:22:21 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
iOS now on 64-bit processors doesn't necessarily use a
hashtable
for refcounting. Basically, only 33 bits of the 64-bit pointer
are used to actually refer to an
On Tue, 22 Apr 2014 13:35:20 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 22 Apr 2014 13:22:19 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
iOS now on 64-bit processors doesn't necessarily
On Tuesday, 22 April 2014 at 17:39:53 UTC, Kapps wrote:
https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
Ctrl +F Repurposed isa Pointer
Ah, ok, the refcount is embedded in the class-table pointer.
On Tuesday, 22 April 2014 at 17:52:28 UTC, Steven Schveighoffer
wrote:
Even doing it the way they have seems unnecessarily complex,
given that iOS 64-bit was brand new.
I dislike this too… The only reason I can think of is that Apple
themselves have code for OS-X that is optimized 64 bit code
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright newshou...@digitalmars.com
wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be memory
safe.
So?
If you see no value in static guarantees of memory safety, then what
On 4/22/2014 2:20 AM, John Colvin wrote:
A system that is automatically safe but can be manually managed for extra
performance. That sounds very D-ish.
Needing to write @system code with a GC to get performance is rare in D. It's
normal in O-C, as has been pointed out here a couple times.
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
Again with the straw man!
If you really believe you can make a performant ARC system, and have it be
memory safe, feel free to write a complete proposal on it.
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be
On Tue, 22 Apr 2014 14:15:35 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
Again with the straw man!
If you really believe you can make a performant ARC system, and have it
be memory safe, feel free to write a complete proposal
On Tuesday, 22 April 2014 at 18:38:28 UTC, Steven Schveighoffer
wrote:
I hope you can understand that from this discussion, I'm not to
motivated to devote time on it. Not that I could do it anyway :)
Do it anyway.
This is such a fun topic and many would be entertained by the
ensuing
On Tue, 22 Apr 2014 14:43:04 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 22 April 2014 at 18:38:28 UTC, Steven Schveighoffer wrote:
I hope you can understand that from this discussion, I'm not to
motivated to devote time on it. Not that I could do it
On 2014-04-22 17:52:27 +, Steven Schveighoffer
schvei...@yahoo.com said:
Even doing it the way they have seems unnecessarily complex, given that
iOS 64-bit was brand new.
Perhaps it's faster that way due to some caching effect. Or perhaps
it's to be able to have static constant string
On Tuesday, 22 April 2014 at 18:48:04 UTC, Steven Schveighoffer
wrote:
I mean not like I can't because I don't want to or don't have
time, but can't as in I lack the skill set :) It's interesting
to debate, and I get the concepts, but I am not a CPU/cache
guy, and these things are really
On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright newshou...@digitalmars.com
wrote:
The thing is, with iOS
On 4/22/2014 11:38 AM, Steven Schveighoffer wrote:
Generally, when investing a lot of time and energy into something, you want to
make sure the market is there first...
Ironic, considering that nobody but me believed there was a market for D before
it existed :-)
I do believe there is a
On Tue, 22 Apr 2014 15:02:05 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014
On Tue, 22 Apr 2014 15:10:31 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/22/2014 11:38 AM, Steven Schveighoffer wrote:
Generally, when investing a lot of time and energy into something, you
want to
make sure the market is there first...
Ironic, considering that nobody but
On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said:
Memory safety is not a strawman. It's a critical feature for a modern
language, and will become ever more important.
What you don't seem to get is that ARC, by itself, is memory-safe.
Objective-C isn't memory safe
On 4/22/2014 12:42 PM, Michel Fortin wrote:
On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said:
Memory safety is not a strawman. It's a critical feature for a modern
language, and will become ever more important.
What you don't seem to get is that ARC, by itself, is
On 4/22/2014 4:00 AM, Don wrote:
It turns out to have enormous value. I will explain this in my DConf talk. A
little preview:
Almost all of our code at Sociomantic obeys this behaviour, and it's probably
the most striking feature of our codebase. By almost all I mean probably 90%
of our code,
Timon Gehr:
In which case? In case some version of LDC2 is able to avoid
the heap allocation using full optimizations? :o)
Please take a look, I have just added one more note in the
optimizations section:
http://wiki.dlang.org/DIP60#Behaviour_in_presence_of_optimizations
Bye,
bearophile
On Fri, 18 Apr 2014 20:17:59 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/18/2014 5:30 AM, Steven Schveighoffer wrote:
Absolutely not, the compiler knows whether the count needs to be
incremented, I
don't need to know.
But there are manual escapes from it, meaning you need
On Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
How bout this!
Why not allow one to define their own attributes from a
generalized subset and then define a few standard ones like
@nogc.
Sounds like you want AST macros. Have a look at this
On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
Total replacement of GC with ARC in D will:
This is the wrong straw-man, I'm not advocating for this at all.
Many are when they advocate ARC for D.
4. Will not be memory safe (see (2))
5. Require the invention of optimization technology
On Monday, 21 April 2014 at 16:45:15 UTC, Jacob Carlborg wrote:
On Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
How bout this!
Why not allow one to define their own attributes from a
generalized subset and then define a few standard ones like
@nogc.
Sounds like you want AST
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
Total replacement of GC with ARC in D will:
This is the wrong straw-man, I'm not advocating for this at all.
Many are when they advocate ARC for D.
Does
On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
Total replacement of GC with ARC in D will:
This is the wrong straw-man, I'm not advocating for this at
Am Sun, 20 Apr 2014 08:19:45 +
schrieb monarch_dodra monarchdo...@gmail.com:
D static initialization doesn't work the same way. Everything is
initialized as the program is loaded, […]
Ah ok, it's all good then :)
Also, just doing this is good enough:
//
void foo() @nogc
{
On Mon, 21 Apr 2014 15:03:18 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
Total replacement
On Monday, 21 April 2014 at 20:29:46 UTC, Steven Schveighoffer
wrote:
example he gives (and I agree with him) is iOS. Just look at
the success of iOS, where the entire OS API is based on ARC
(actually RC, with an option for both ARC and manual, but the
latter is going away). If ARC was so bad,
On Monday, 21 April 2014 at 20:29:46 UTC, Steven Schveighoffer
wrote:
It's pretty difficult to use manual RC and beat ARC. In fact in
some cases, ARC can beat manual, because the compiler has more
insight and knowledge of the rules being followed.
Are you sure? Have you tried to do it first
Here are two very good reasons to avoid extensive ref-counting:
1. transactional memory ( you don't want a lock on two reads )
2. cache coherency ( you don't want barriers everywhere )
Betting everything on ref counting is the same as saying no to
upcoming CPUs.
IMO that means ARC is DOA.
On Sunday, 20 April 2014 at 18:48:49 UTC, John Colvin wrote:
The way I understood your idea, was that a template could be
marked @nogc, and yet still allow template arguments that
themselves may gc.
This can be accomplished by creating a unit test that passes
non-allocating template
On 4/21/2014 1:29 PM, Steven Schveighoffer wrote:
I think you are misunderstanding something. This is not for a pervasive
ARC-only, statically guaranteed system. The best example he gives (and I agree
with him) is iOS. Just look at the success of iOS, where the entire OS API is
based on ARC
On Saturday, 19 April 2014 at 23:44:45 UTC, Marco Leise wrote:
Am Wed, 16 Apr 2014 20:32:20 +
schrieb Peter Alexander peter.alexander...@gmail.com:
On Wednesday, 16 April 2014 at 20:29:17 UTC, bearophile wrote:
Peter Alexander:
(I assume that nothrow isn't meant to be there?)
In D
On 2014-04-19 15:40, monarch_dodra wrote:
Nonsense. It still works 99% of the time (I think only a subset of 100
letters in all of Unicode are affect, and even then, another 100 of them
*shrink* on toUpper). It is really useful. It avoids *needles*
allocations. Removing it would be more harmful
On Wednesday, 16 April 2014 at 02:14:18 UTC, Walter Bright wrote:
On 4/15/2014 6:57 PM, Mike wrote:
I suspect some of the motivation for this is to give customers
faster horses.
I would be surprised if a @nogc attribute increased D's
appeal, and I think
efforts would be better allocated to
1 - 100 of 355 matches
Mail list logo
