On Wednesday, 29 June 2016 at 17:25:31 UTC, Atila Neves wrote:
On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
On 6/25/2016 3:44 PM, Walter Bright wrote:
4. Add @safe to the unittest
A unittest that is deliberately unsafe should be annotated
with @system. Meaning that any un
On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
On 6/25/2016 3:44 PM, Walter Bright wrote:
4. Add @safe to the unittest
A unittest that is deliberately unsafe should be annotated with
@system. Meaning that any un-annotated unittest needs
corrective action one way or the
On 06/28/2016 05:34 PM, Robert burner Schadek wrote:
On Monday, 27 June 2016 at 19:33:45 UTC, Walter Bright wrote:
Sorry to have offended you, I worded things badly. Thank you for
making the list. It's just that I'm feeling a bit overwhelmed at the
moment with trying to get things done and being
On Monday, 27 June 2016 at 19:33:45 UTC, Walter Bright wrote:
Sorry to have offended you, I worded things badly. Thank you
for making the list. It's just that I'm feeling a bit
overwhelmed at the moment with trying to get things done and
being asked to do more every day, and I'd like to delegat
On 6/27/2016 8:14 AM, Robert burner Schadek wrote:
On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote:
It's a wiki, feel free to add it.
I have to say that reply really makes me angry. I created that list so Andrei
and you have an easy to find spot where you can write down tasks so p
On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote:
It's a wiki, feel free to add it.
I have to say that reply really makes me angry. I created that
list so Andrei and you have an easy to find spot where you can
write down tasks so people can work on them. You did not disagree
with
On 6/26/2016 6:13 AM, Robert burner Schadek wrote:
It would be awesome if you would create that process model in the wiki and at it
to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List
It's a wiki, feel free to add it.
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the
incomplete implementation of @safe. I'm working on the compiler
end. But Phobos has a lot of code that is pointlessly not
@safe, making it frustrating to write @safe code
It would be awesome if you would create that process model in the
wiki and at it to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List
So it does not get lost and people can find it.
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the
incomplete implementation of @safe. I'm working on the compiler
end. But Phobos has a lot of code that is pointlessly not
@safe, making it frustrating to write @safe code
On Sunday, June 26, 2016 06:29:05 Tourist via Digitalmars-d wrote:
> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
> > On 6/25/2016 3:44 PM, Walter Bright wrote:
> >> 4. Add @safe to the unittest
> >
> > A unittest that is deliberately unsafe should
On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
On 6/25/2016 3:44 PM, Walter Bright wrote:
4. Add @safe to the unittest
A unittest that is deliberately unsafe should be annotated with
@system. Meaning that any un-annotated unittest needs
corrective action one way or the
On 6/25/2016 3:44 PM, Walter Bright wrote:
4. Add @safe to the unittest
A unittest that is deliberately unsafe should be annotated with @system. Meaning
that any un-annotated unittest needs corrective action one way or the other.
Debugging tip:
Templates should almost never be marked @safe or @trusted, as the safety should
be inferred. However, to isolate down where the unsafe code actually is, add
@safe temporarily to the template declaration. Then, the compiler will tell you
which line in the template is unsafe.
Andrei identified a key blocker for D adoption is the incomplete implementation
of @safe. I'm working on the compiler end. But Phobos has a lot of code that is
pointlessly not @safe, making it frustrating to write @safe code that calls
Phobos. Some are listed in Bugzilla, most are not.
On Tuesday, 23 February 2016 at 11:04:31 UTC, Nick Treleaven
wrote:
Assuming we don't want to disallow slice.ptr in @safe code,
maybe we could have the compiler insert this code before
reading slice.ptr:
version(D_NoBoundsChecks) else
if (slice.length == 0) throw new RangeError(&q
g.org/show_bug.cgi?id=11176
Assuming we don't want to disallow slice.ptr in @safe code, maybe
we could have the compiler insert this code before reading
slice.ptr:
version(D_NoBoundsChecks) else
if (slice.length == 0) throw new RangeError("Unsafe .ptr on
empty array");
at some Phobos modules (*ahem*std.socket*cough*)
> >>liberally sprinkle @trusted on every function without regard to
> >>whether it's truly justified
> >[...]
> >
> >I don't like being the guy who only whines but does nothing about it,
> >so here
27;s truly justified
[...]
I don't like being the guy who only whines but does nothing about it, so
here's an attempt at plugging at least one of the holes in the @safe
cheese grater:
https://github.com/D-Programming-Language/phobos/pull/4011
Here's an existing one that plugs a
e being the guy who only whines but does nothing about it, so
here's an attempt at plugging at least one of the holes in the @safe
cheese grater:
https://github.com/D-Programming-Language/phobos/pull/4011
Here's an existing one that plugs another hole in the cheese grater:
On 18.02.2016 21:57, H. S. Teoh via Digitalmars-d wrote:
>If you want to verify guarantees, @safe should be specified by
>inclusion and ideally, type safety should be proved formally (after
>applying a few fixes).
>This first requires a formal language semantics.
>That's alr
;
>> foo(void[] arr)
>> {
>>void[] arr2 = [1234, 5678, 91011];
>>arr[] = arr2[0 .. arr.length];
>> }
>
> Since void throws away type information (and all the safety
> related to it), would it be easier to simply require @safe code can't
> cast i
mars-d wrote:
>>On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
>>Schveighoffer wrote:
>[...]
>>>foo(void[] arr)
>>>{
>>> void[] arr2 = [1234, 5678, 91011];
>>> arr[] = arr2[0 .. arr.length];
>>>}
>>
>>Well, I'm n
On Thu, Feb 18, 2016 at 08:23:24PM +0100, Timon Gehr via Digitalmars-d wrote:
> On 18.02.2016 19:41, H. S. Teoh via Digitalmars-d wrote:
[...]
> > void breakSafety(void[] data) @safe
> > {
> > union U {
> > void[] d;
> &
On Thu, Feb 18, 2016 at 07:28:16PM +, Kagamin via Digitalmars-d wrote:
> On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
> >(*ahem*std.socket*cough*) liberally sprinkle @trusted on every function
> >without regard to whether it's truly justified (e.g., see
> >https://issues.dla
ary 2016 at 18:41:25 UTC, Steven Schveighoffer
> >>wrote:
> >[...]
> >>>foo(void[] arr)
> >>>{
> >>> void[] arr2 = [1234, 5678, 91011];
> >>> arr[] = arr2[0 .. arr.length];
> >>>}
> >>
> >>Well, I'
On 2/18/16 2:25 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 01:58:24PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation
is rather lackluster
On Thursday, 18 February 2016 at 18:58:24 UTC, Steven
Schveighoffer wrote:
And implicit casts to void[] should be disallowed.
We could strike a sane medium: in a @safe function or when
calling a @safe function, implicit conversions of any array WITH
REFERENCES is not allowed, while other
On Thursday, 18 February 2016 at 19:28:16 UTC, Kagamin wrote:
On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
(*ahem*std.socket*cough*) liberally sprinkle @trusted on every
function without regard to whether it's truly justified (e.g.,
see https://issues.dlang.org/show_bug.cgi?
On Thu, Feb 18, 2016 at 01:58:24PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
> >While @safe is a good idea in principle, the current implementation
> >is rather lackluster.
>
> IMO, I think safe code sh
Well, ok, getprotobyname indeed looks thread unsafe for some
reason, but this can happen for any function.
On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
(*ahem*std.socket*cough*) liberally sprinkle @trusted on every
function without regard to whether it's truly justified (e.g.,
see https://issues.dlang.org/show_bug.cgi?id=15672)
How is bug 15672 related to std.socket? From quick
[] = arr2[0 .. arr.length];
}
Since void throws away type information (and all the safety related to
it), would it be easier to simply require @safe code can't cast
implicitly to void? It seems like explicit casting would take care of
most of this, or disallowing to/from void converting p
78, 91011];
> arr[] = arr2[0 .. arr.length];
>}
Well, I'm not sure that that's actually not @safe.
How can it possibly be @safe??? Consider:
void main() @safe {
Object[] objs = [ new Object() ];
foo(objs);
}
Now the pointer to the
.dlang.org/show_bug.cgi?id=15702
No problem here. There is no way to assign to a void[] without doing 2.
Sure there is:
void breakSafety(void[] data) @safe
{
union U {
void[] d;
int[] arr;
}
throws away type information (and all the safety
related to it), would it be easier to simply require @safe code
can't cast implicitly to void? It seems like explicit casting
would take care of most of this, or disallowing to/from void
converting period while in @safe code.
To be hone
On 2/18/16 1:50 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer wrote:
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[] = arr2[0 .. arr.length];
}
Well, I'm not sure that that's actually not @safe. It's trying t
On Thu, Feb 18, 2016 at 06:55:18PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 18:41:58 UTC, H. S. Teoh wrote:
[...]
> >It's only one of many culprits. As long as there is any way around
> >@safe, the entire system of guarantees breaks
gt; >}
>
> Well, I'm not sure that that's actually not @safe.
How can it possibly be @safe??? Consider:
void main() @safe {
Object[] objs = [ new Object() ];
foo(objs);
}
Now the pointer to the Object instance has been corrupte
On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster.
IMO, I think safe code should disallow casting that doesn't involve a
runtime function that verifies safety (such as casting an object to
an
On Thursday, 18 February 2016 at 18:41:58 UTC, H. S. Teoh wrote:
On Thu, Feb 18, 2016 at 07:30:34PM +0100, Timon Gehr via
Digitalmars-d wrote:
No problem here. There is no way to assign to a void[] without
doing 2.
Sure there is:
void breakSafety(void[] data) @safe
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current
implementation is
rather lackluster. Consider, for example:
void
On 18.02.2016 19:41, Steven Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer
r, not void[].
> >
> > https://issues.dlang.org/show_bug.cgi?id=15702
> >
>
> No problem here. There is no way to assign to a void[] without doing 2.
Sure there is:
void breakSafety(void[] data) @safe
{
union U {
void[]
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
buf
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
buf[0] = 0xFF;
}
void main() @safe
On Fri, 12 Feb 2016 14:32:32 -0500, Steven Schveighoffer wrote:
> what I'm trying to say safe shouldn't allow is reinterpret casting.
> i.e.: *cast(T*)(&x)
>
> So casting IMO shouldn't be allowed unless it invokes some kind of
> handler that ensures the conve
On 2/12/16 12:15 PM, Chris Wright wrote:
Casting between primitive value types (eg long -> int) is @safe. You
can't get memory errors that way, and the conversions are well-defined.
Casting between object references is @safe (assuming the object
references are valid; @safe doesn'
On Fri, 12 Feb 2016 08:45:54 -0500, Steven Schveighoffer wrote:
> A cast to const may be viable.
Touché.
> However, I think casting in safe code is
> probably not something to allow.
*All* casting?
Casting between primitive value types (eg long -> int) is @safe. You
can't
pointer to it.
@safe should start from a very cautious and overtightened state, and
then we loosen it as we find issues.
As it was done, it has holes, and so when we fix things, code breaks.
I agree with the principle, but it's always safe to read a pointer as if
it were not a pointer, and t
On Wed, 10 Feb 2016 22:39:20 -0500, Steven Schveighoffer wrote:
> I think casting a mutable array to any array type is a recipe for memory
> issues, no matter what is in the elements. Remember that you are casting
> a reference that still has a mutable pointer to it.
>
> @safe sh
On 2/10/16 5:49 PM, Chris Wright wrote:
On Wed, 10 Feb 2016 21:40:21 +, Iakh wrote:
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright wrote:
@safe protects you from segmentation faults and reading and writing
outside an allocated segment of memory. With array casts, @safety is
On Wed, 10 Feb 2016 22:49:33 +, Chris Wright wrote:
> It should always be safe to cast from void[] to immutable(T)[] where T
> doesn't contain pointers.
>
> I didn't see a bug for this, so I'm filing it.
Filed https://issues.dlang.org/show_bug.cgi?id=15672
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright
wrote:
Show a way to read or write outside allocated memory with this,
or to cause a segmentation fault, and that will require a
change in @safe. You're looking for something else, data safety
rather than memory safety. You wa
On Wed, 10 Feb 2016 21:40:21 +, Iakh wrote:
> On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright wrote:
>> @safe protects you from segmentation faults and reading and writing
>> outside an allocated segment of memory. With array casts, @safety is
>> assured
>
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright
wrote:
@safe protects you from segmentation faults and reading and
writing outside an allocated segment of memory. With array
casts, @safety is assured
Yes, @safe protects from direct cast to/from ref types but there
still is a
e problem is like this.
>
> @safe int* badCast(long[] slice) {
> return (cast(int[]) slice).ptr;
> }
>
>
> @system void main(string[] argv) {
> auto larger = new long[5];
> auto smaller = badCast(larger);
> }
@safe protects you from segmentation
Yeah, I think it should only allow the equivalent of a
dynamic_cast for types in @safe code, and not allow the
equivalent of a reinterpret_cast, for T, T*, or T[].
hat have pointers or references
overlapping with other types.
"reinterpret cast" is allowed using unions but only for some
types. So array casting could be allowed for same set of types.
e.g cast(T)arrB allowed if below compiles:
() @safe {
union
{
T a;
typeof(arraB[0]) b;
}
cast from one type to another? Depends.
If they are nearly the same (signed vs unsigned) maybe it should
be allowed. Completely different types (or of different lengths)?
I'd say not with @safe declared; But still there's many many many
low level tricks and bypasses we have to do to get
On Tuesday, 9 February 2016 at 21:20:53 UTC, Iakh wrote:
https://dlang.org/spec/function.html#function-safety
Current definition of safety doesn't mention cast of arrays.
E.g this code allowed by DMD
int[] f(void[] a) @safe pure
{
return cast(int[])a;
}
But same void* to int* ca
https://dlang.org/spec/function.html#function-safety
Current definition of safety doesn't mention cast of arrays.
E.g this code allowed by DMD
int[] f(void[] a) @safe pure
{
return cast(int[])a;
}
But same void* to int* cast is forbidden.
So we need some rules for dynamic arrays ca
themselves via a
reference!
AFAIK it just traverse members and search for exactly match with
return
type. Even more there is different checks for "pure" and "unique
owned
result".
import std.stdio;
int[] f(void[] a) @safe pure
{
return cast(int[])a;
}
void main()
within the function and that
therefore the return value is the only reference to that data, and so
it's safe to alter its mutability - e.g. change a mutable array to an
immutable one. Exactly which conditions under which that can be
determined to be safe are not exactly straightforward. The sim
B : A)
behaves the same way as original:
import std.stdio;
class A
{
int i;
}
class B : A
{
}
struct S
{
A a;
auto f() pure @safe
{
B b = new B;
a = b;
return b;
}
}
void main() @safe
{
S s;
immutable a = s.f();
A b = s.a;
writeln(a.i);
On Monday, 8 February 2016 at 20:07:49 UTC, Iakh wrote:
On Monday, 8 February 2016 at 19:33:54 UTC, Jesse Phillips
wrote:
I'm pretty sure this is not safe. Works, but not safe. You
So it is bug?
Yeah, I missed a couple items of your code. You'd marked the
functions @safe, an
On 08.02.2016 22:14, Iakh wrote:
Is all prams being const(but not immutable) not enough for
function to be Pure?
The hidden `this` parameter must be const, too. And mutable indirections
in the return type must be considered.
This article explains it in detail:
http://klickverbot.at/blog/2012
d within the function and that therefore the return value
is the only reference to that data, and so it's safe to alter its
mutability - e.g. change a mutable array to an immutable one.
Exactly which conditions under which that can be determined to be
safe are not exactly straightforwar
On Monday, 8 February 2016 at 20:43:23 UTC, Jonathan M Davis
wrote:
in a bug report should be sufficient to show the bug, even
without the rest of what you're doing.
In general, it should be impossible for member functions to be
considered strongly pure unless they're marked as immutable,
On Monday, 8 February 2016 at 19:07:01 UTC, Iakh wrote:
import std.stdio;
struct S
{
void[] arr;
auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr
On Monday, 8 February 2016 at 19:33:54 UTC, Jesse Phillips wrote:
I'm pretty sure this is not safe. Works, but not safe. You
So it is bug?
On Monday, 8 February 2016 at 19:07:01 UTC, Iakh wrote:
import std.stdio;
struct S
{
void[] arr;
auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr
import std.stdio;
struct S
{
void[] arr;
auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a);
b[0] = 1;
writeln(a);
}
http
On 1/21/16 10:43 PM, Chris Wright wrote:
I wanted to use std.array.insertInPlace in a @safe module. It's not
marked @safe or @trusted. The string implementation uses pointer
arithmetic, and the non-string implementation uses memmove.
Should things like this be marked @trusted in ge
I wanted to use std.array.insertInPlace in a @safe module. It's not
marked @safe or @trusted. The string implementation uses pointer
arithmetic, and the non-string implementation uses memmove.
Should things like this be marked @trusted in general?
Presumably if a function isn't memor
On Sunday, 20 December 2015 at 13:18:45 UTC, Paulo Pinto wrote:
Hello,
Joe Duffy just published another Midori article, how they have
written the OS in an extended version of C#, which started as
part of the Singularity OS.
https://news.ycombinator.com/item?id=10766436
Interesting read, spe
Hello,
Joe Duffy just published another Midori article, how they have
written the OS in an extended version of C#, which started as
part of the Singularity OS.
https://news.ycombinator.com/item?id=10766436
Interesting read, specially since many of the learned lessons are
now coming to the s
On Monday, 7 December 2015 at 07:10:42 UTC, Sönke Ludwig wrote:
I've very likely missed that part of the discussion - what were
the reasons to not use "scope" for this?
Yeah good point, it should be possible to reuse scope as method
attribute. I just used @noescape as a placeholder for the
di
Am 01.11.2015 um 21:47 schrieb Martin Nowak:
On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
- I'm not a fan of adding yet another attribute but as inference support
is currently limited it seems we'd need an explicit attribute for
public APIs.
I've very likely missed that part of the
On Saturday, 5 December 2015 at 22:06:33 UTC, sclytrack wrote:
On Monday, 2 November 2015 at 09:56:14 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak
wrote:
On 11/01/2015 09:51 PM, Martin Nowa
On Monday, 2 November 2015 at 09:56:14 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
http://lists.puremagic.com/cgi-bin/mailman/listinfo/
On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
Yes but
On 11/1/15 5:52 PM, rsw0x wrote:
On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote:
On 11/01/2015 03:51 PM, Martin Nowak wrote:
On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
Unrelated, and a foreshadowing of the discussion on the lifetime
mailing
list: the compiler has
On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu
wrote:
On 11/01/2015 03:51 PM, Martin Nowak wrote:
On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
Unrelated, and a foreshadowing of the discussion on the
lifetime mailing
list: the compiler has ample opportunity to fuse incs/de
On 11/01/2015 03:54 PM, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
My understanding is that no, that won't happen in most patterns that
matter. -- Andrei
On 11/01/2015 03:51 PM, Martin Nowak wrote:
On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
Unrelated, and a foreshadowing of the discussion on the lifetime mailing
list: the compiler has ample opportunity to fuse incs/decs together, so
the signatures of these functions is:
void opInc(uint d
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
Yes but you have this myth flying around that it is necessary for
goo
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
AFAIK the fear of RC being too slow comes from C++'s shared_ptr's
ref
On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
> It follows that if we want safe reference counting, there must be
> language support for it. One possibility is to attach an attribute to
> the class definition:
>
> @safe @rc class Widget {
> ...
> }
Let's thi
On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
> Unrelated, and a foreshadowing of the discussion on the lifetime mailing
> list: the compiler has ample opportunity to fuse incs/decs together, so
> the signatures of these functions is:
>
> void opInc(uint delta);
> void opDec(uint delta);
Any
On 11/01/2015 09:51 PM, Martin Nowak wrote:
> Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
vel a compiler support
to be safe. That being said, the support does not need to be
specific to RC. On fact, my position is that the language
should provide some basic mechanism on top of which safe RC
can be implemented, as a library.
The problem at hand here is escape analysis. The compiler
On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
I've made the claim that we should implement reference counting
as a library many time, so I think I should explicit my
position. Indeed, RC require some level a compiler support to
be safe. That being said, the support doe
On 10/28/2015 7:58 AM, Andrei Alexandrescu wrote:
On 10/28/2015 04:13 AM, Jacob Carlborg wrote:
On 2015-10-27 22:19, Andrei Alexandrescu wrote:
That doesn't seem to be the case at all. -- Andrei
I'm not a C++ or Rust expert. But I think that in Rust and with the new
C++ guide lines the idea
On 2015-10-28 09:50, Paulo Pinto wrote:
Hence why I mentioned they are more RC friendly.
Swift, because it doesn't have them.
Objective-C, because termination is the only option so no need to worry
about preserving counters.
I was typing on the phone, so didn't want to provide the full explan
On 10/28/2015 04:13 AM, Jacob Carlborg wrote:
On 2015-10-27 22:19, Andrei Alexandrescu wrote:
That doesn't seem to be the case at all. -- Andrei
I'm not a C++ or Rust expert. But I think that in Rust and with the new
C++ guide lines the idea is to use reference counting pointers only for
owni
On 28 October 2015 at 21:29, David Nadlinger via Digitalmars-d
wrote:
> On Wednesday, 28 October 2015 at 11:21:17 UTC, Manu wrote:
>>
>> RC is okay-ish in C++11 (with rval references), although it could be
>> much better, for instance, the type mangling/wrapping induced by this
>> sort of library
On Wednesday, 28 October 2015 at 11:21:17 UTC, Manu wrote:
RC is okay-ish in C++11 (with rval references), although it
could be
much better, for instance, the type mangling/wrapping induced
by this
sort of library solution always leads to awkward situations, ie,
'this' pointer in a method is no
d, RC require
>> some
>> level a compiler support to be safe. That being said, the support does not
>> need
>> to be specific to RC. On fact, my position is that the language should
>> provide
>> some basic mechanism on top of which safe RC can be implemented, as a
301 - 400 of 1631 matches
Mail list logo
