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
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 examp
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 form),
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
"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 ag
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:
https://issues.dl
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 c
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 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 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
@nogc
On Fri, 25 Apr 2014 20:50:46 -0400, Ola Fosheim Grøstad
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 let's you get "compiler-optimal
non
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 Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot
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). Unfortunately, with no succes
On Fri, 25 Apr 2014 11:29:37 -0400, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot 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 as
@nogc that compiles on compiler
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot 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 attributes must be placed
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 co
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 t
On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot 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 a practical optimi
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 08:21:38 -0400, 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
On Fri, 25 Apr 2014 08:21:38 -0400, 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 re
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 re
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: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 desirabl
On Fri, 25 Apr 2014 07:28:27 -0400, Ola Fosheim Grøstad
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 a closure
with the GC
Such kin
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 @
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 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 mak
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 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];
immutable
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, 2,
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 mine
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.
To
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 t
On Wed, 23 Apr 2014 02:11:38 -0400, Jacob Carlborg 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 CPU/cache guy
On Wed, 23 Apr 2014 05:14:44 -0400, Manu via Digitalmars-d
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 not? Assuming that direct acce
On 2014-04-23 04:33:00 +, Walter Bright said:
On 4/22/2014 12:42 PM, Michel Fortin wrote:
On 2014-04-22 19:02:05 +, Walter Bright 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 i
On 2014-04-23 09:50:57 +, "Ola Fosheim Grøstad"
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
undefined behaviours inherited from
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 A
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 April 2014 04:28, Steven Schveighoffer via Digitalmars-d
wrote:
> On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
> wrote:
>
>> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>>>
>>> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
>>>
>>> wrote:
The thing is, with iOS ARC,
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 design,
On 22 April 2014 05:03, Walter Bright via Digitalmars-d
wrote:
> On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
>>
>> On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
>>
>> wrote:
>>
>>> On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
>
> Total replacement of GC with ARC in D will:
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 perf
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 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, i
On 4/22/2014 12:42 PM, Michel Fortin wrote:
On 2014-04-22 19:02:05 +, Walter Bright 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.
I repeatedly
On 2014-04-22 19:02:05 +, Walter Bright 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 because it lets you play wit
On Tue, 22 Apr 2014 15:10:31 -0400, Walter Bright
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 me believed there was a ma
On Tue, 22 Apr 2014 15:02:05 -0400, Walter Bright
wrote:
On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
wrote:
The thing i
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 mark
On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be memory
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 import
On 2014-04-22 17:52:27 +, "Steven Schveighoffer"
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 objects in the read
On Tue, 22 Apr 2014 14:43:04 -0400, Ola Fosheim Grøstad
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 anyway :)
Do it anyway.
I mean not
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 excruciat
On Tue, 22 Apr 2014 14:15:35 -0400, Walter Bright
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 it.
I hope you can unde
On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright
wrote:
On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
wrote:
The thing is, with iOS ARC, it cannot be statically guaranteed to be
memory safe.
So?
If you see no value in static gua
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 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:
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
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 can I say?
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 Tue, 22 Apr 2014 13:35:20 -0400, Steven Schveighoffer
wrote:
On Tue, 22 Apr 2014 13:22:19 -0400, 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 bit
On Tue, 22 Apr 2014 13:22:19 -0400, 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 address, the
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 address,
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 cou
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 whi
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 isn
On Tue, 22 Apr 2014 09:48:28 -0400, Ola Fosheim Grøstad
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 know what happens to the
pointers
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 D-functo
On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad
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 whether data is shared or not.
I don
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
function
On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
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 him) is iOS. Just look at t
On Mon, 21 Apr 2014 17:52:30 -0400, Ola Fosheim Grøstad
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 )
Betting everything on ref counting is the
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 GC-tr
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) == (1<
On Tuesday, 22 April 2014 at 09:01:20 UTC, Walter Bright wrote:
On 4/21/2014 11:51 PM, "Ola Fosheim Grøstad"
" wrote:
This is actually quite efficient compared to the standard
NSObject which uses a
hashtable for refcounting:
It's not efficient compared to pointers.
It isn't efficient compar
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
case.
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 4/21/2014 11:51 PM, "Ola Fosheim Grøstad"
" 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 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 be
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 e
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:
http://www.opensource.apple.
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 (actu
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 parameter
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. It
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 wi
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 Mon, 21 Apr 2014 15:03:18 -0400, Walter Bright
wrote:
On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
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-ma
Am Sun, 20 Apr 2014 08:19:45 +
schrieb "monarch_dodra" :
> 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
> {
> static err =
On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
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 advo
On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
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 that preclude you from acce
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 mac
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 that
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
http://wiki.dlang.org/DIP50#Declaration
On Fri, 18 Apr 2014 20:17:59 -0400, Walter Bright
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 to know to use
them:
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 Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
Why not allow one to define their own attributes from a
generalized subset and then define a few standard ones like
@nogc.
i.e., instead of having to define specific attributes every few
years to satisfy some new thing, why not just
On Saturday, 19 April 2014 at 18:41:39 UTC, Walter Bright wrote:
On 4/19/2014 11:05 AM, Dicebot wrote:
I feel like the origin of the discussion has been completely
lost here and we
don't speak the same language right now. The very point I have
made initially is
that @nogc in a way it is defined
On Sunday, 20 April 2014 at 15:04:28 UTC, Rikki Cattermole wrote:
On Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
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 "fast
1 - 100 of 356 matches
Mail list logo
