Re: string literal string and immutable(char)* overload ambiguity

y. It should be the same as foo(long) vs. foo(int) with foo(1). +1 for this Although there is a solution for this today, i.e. foo(cast(string)"baz"); foo("baz".ptr)); I see no reason why `string` shouldn't have precedence over `immutable(char)*`, especially since you

Re: string literal string and immutable(char)* overload ambiguity

On 8/3/18 10:26 AM, Jonathan Marler wrote: On Tuesday, 31 July 2018 at 15:07:04 UTC, Steven Schveighoffer wrote: On 7/31/18 10:13 AM, Nicholas Wilson wrote: is there any particular reason why void foo(string a) {} void foo(immutable(char)* b) {} void bar() { foo("baz"); }

Re: string literal string and immutable(char)* overload ambiguity

On Tuesday, 31 July 2018 at 15:07:04 UTC, Steven Schveighoffer wrote: On 7/31/18 10:13 AM, Nicholas Wilson wrote: is there any particular reason why void foo(string a) {} void foo(immutable(char)* b) {} void bar() {     foo("baz"); } result in Error: foo called with argument typ

Re: string literal string and immutable(char)* overload ambiguity

In the C++ language, programmers or the users have to face any kind of problems like mutable or immutable objects in the String category. The problem actually arises due to the ambiguity. You may take a suggestion from https://mailhelp.net/gmail-support/ that will help you to resolve such a

Re: string literal string and immutable(char)* overload ambiguity

On 7/31/18 10:13 AM, Nicholas Wilson wrote: is there any particular reason why void foo(string a) {} void foo(immutable(char)* b) {} void bar() {     foo("baz"); } result in Error: foo called with argument types (string) matches both: foo(string a) and: foo(immutable(char)* b)

string literal string and immutable(char)* overload ambiguity

is there any particular reason why void foo(string a) {} void foo(immutable(char)* b) {} void bar() { foo("baz"); } result in Error: foo called with argument types (string) matches both: foo(string a) and: foo(immutable(char)* b) especially given the pointer overload is alm

Augh, nevermind, it's immutable TimeZone

Augh, nevermind, it's immutable TimeZone. TimeZone needs to be immutable for some reason, so it needs Rebindable, so SysTime has opAssign anyways, because there's no native way to specify a tailconst for class references. Augh. Maybe it's finally time to write an emplace-b

Re: partially mutable immutable type problem, crazy idea

app.d(1):onlineapp.f(T)(immutable T a) Not supposed to. Was proposing an (crazy) idea here.

Re: partially mutable immutable type problem, crazy idea

On Tuesday, 8 May 2018 at 22:31:10 UTC, Yuxuan Shui wrote: snip] This doesn't compile for me on run.dlang.io: onlineapp.d(22): Error: template onlineapp.f cannot deduce function from argument types !()(B), candidates are: onlineapp.d(1):onlineapp.f(T)(immutable T a)

Re: partially mutable immutable type problem, crazy idea

After watching the DConf 2018 video, I came up with this wild idea: auto f(T)(immutable T a) { // If T is a aggregate type, and I only use (directly // or indirectly) the immutable fields of T, // Then it should be OK to call f() with a partially mutable type return a.x+1

Re: immutable postblit unusable?

On 2/11/18 3:25 AM, Jonathan M Davis wrote: In the case of immutable, the postblit is actually completely unnecessary, because there's no need to do a deep copy of an immutable object, since it's guaranteed to never change its value (whereas with const, a deep copy can still be necess

Re: immutable postblit unusable?

issue opened here: https://issues.dlang.org/show_bug.cgi?id=18417 thanks Jon

Re: immutable postblit unusable?

On Sunday, 11 February 2018 at 08:25:41 UTC, Jonathan M Davis wrote: … Thanks, I couldn't have asked for a more thorough explanation. Especially that __xpostblit detail, which I now vaguely recall seeing in the runtime code. Sounds like making `this(this) immutable` illegal is the w

Re: immutable postblit unusable?

On Sunday, February 11, 2018 07:50:52 Cauterite via Digitalmars-d wrote: > https://dpaste.dzfl.pl/80d2a208519c > > struct A { > this(this) immutable {} > } > > struct B { > A a; > } > > // Error: immutable method f18.A.__postblit is not

immutable postblit unusable?

https://dpaste.dzfl.pl/80d2a208519c struct A { this(this) immutable {} } struct B { A a; } // Error: immutable method f18.A.__postblit is not callable using a mutable object - I honestly don't know what to make of this. I guess the auto-gene

Re: functions allowed to overload on const int vs int vs immutable int? + spec is not accurate

fun(int src){ writeln2(); } > void fun(immutable int src){ writeln2(); } > void fun(const int src){ writeln2(); } There is also `inout` and `shared`. Granted, for basic types it makes no difference, but once references are involved you benefit from keeping the qualifier. A const or mutable string

functions allowed to overload on const int vs int vs immutable int? + spec is not accurate

this compiles, but equivalent in C++ (const int vs int) would give a compile error (error: redefinition of 'fun'); what's the rationale for allowing these overloads? ``` void fun(int src){ writeln2(); } void fun(immutable int src){ writeln2(); } void fun(const int src){ writeln2(

functions allowed to overload on const int vs int vs immutable int? + spec is not accurate

this compiles, but equivalent in C++ (const int vs int) would give a compile error (error: redefinition of 'fun'); what's the rationale for allowing these overloads? ``` void fun(int src){ writeln2(); } void fun(immutable int src){ writeln2(); } void fun(const int src){ writ

Re: static immutable AAs documentation

On Friday, December 15, 2017 03:49:53 Luís Marques via Digitalmars-d wrote: > The documentation for AAs gives out this example > (<https://dlang.org/spec/hash-map.html#static_initialization>): > > immutable long[string] aa = [ >"foo": 5, >

static immutable AAs documentation

The documentation for AAs gives out this example (<https://dlang.org/spec/hash-map.html#static_initialization>): immutable long[string] aa = [ "foo": 5, "bar": 10, "baz": 2000 ]; unittest { assert(aa["fo

How immutable is an object's vptr?

Hi all, I'm working on (basic) devirtualization, and am wondering how immutable the vptr is in D. There is no clear spec on this. I am currently assuming that an object's vptr is completely immutable and that use of the object after changes to its vptr are UB (in contrast t

Re: How immutable is an object's vptr?

On Saturday, 11 November 2017 at 12:52:09 UTC, Johan Engelen wrote: Hi all, I'm working on (basic) devirtualization, and am wondering how immutable the vptr is in D. There is no clear spec on this. I am currently assuming that an object's vptr is completely immutable and that

Re: Result of CTFE should be implicitly castable to immutable

On Wednesday, 11 October 2017 at 14:30:54 UTC, Dmitry Olshansky wrote: My motivation is, of course, std.regex. static immutable r = regex("abc"); This is perfectly fine but because in general there is some amount of impurtiy in regex and it won't work. Yet regex is called at C

Re: Result of CTFE should be implicitly castable to immutable

On 10/11/17 10:30 AM, Dmitry Olshansky wrote: My motivation is, of course, std.regex. static immutable r = regex("abc"); This is perfectly fine but because in general there is some amount of impurtiy in regex and it won't work. Yet regex is called at CTFE so there is no wa

Result of CTFE should be implicitly castable to immutable

My motivation is, of course, std.regex. static immutable r = regex("abc"); This is perfectly fine but because in general there is some amount of impurtiy in regex and it won't work. Yet regex is called at CTFE so there is no way it can escape mutable pointer to its result. Thoughts?

Re: cannot implicitly convert expression (array(map(split("a")))) of type string[][] to immutable(string[][])

On Sunday, 29 January 2017 at 07:37:00 UTC, Fangrui Song wrote: What cannot `string[][]` be implicitly converted to `immutable(string[][])` as in `not_compilable`? import std.stdio, std.range, std.algorithm, std.array; void main() { immutable not_compilable = "a".split.map!(x

cannot implicitly convert expression (array(map(split("a")))) of type string[][] to immutable(string[][])

What cannot `string[][]` be implicitly converted to `immutable(string[][])` as in `not_compilable`? import std.stdio, std.range, std.algorithm, std.array; void main() { immutable not_compilable = "a".split.map!(x => x.split).array; static immutable compilable0 = &qu

Re: Is this a bug? Initializing immutable fixed size arrays

On Monday, 12 December 2016 at 06:43:52 UTC, Shachar Shemesh wrote: The following compiles fine: immutable char[5] array = x"01 02 03 04 05"; [...] This doesn't seem like a bug: immutable ubyte[5] array = x"01 02 03 04 05"; This however does: immutable ubyte[5] arr

Is this a bug? Initializing immutable fixed size arrays

The following compiles fine: immutable char[5] array = x"01 02 03 04 05"; The following doesn't: immutable ubyte[5] array = x"01 02 03 04 05"; which makes sense, but neither does: immutable ubyte[5] array = cast(immutable ubyte []) x"01 02 03 04 05"; playgr

Re: calling convention optimisation & const/immutable ref

so, how would I turn the optimization off (I guess extern(C++) would do that?)? What if my function needs a local copy (say, in multithreaded stuff), and I want that copy to be const? -Johan Aliasing is not an issue when LargeThing is immutable, is it ?

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 16:48:55 UTC, John Colvin wrote: Some people use ref for performance to prevent the copying that must occur when passing by value. This reminds me of an LLVM presentation by Chandler, mentioning that passing by reference may hamper the optimization of code (becau

Re: calling convention optimisation & const/immutable ref

a given parameter would otherwise be copied and passed on the stack: 1) immutable parameters to all functions are passed by reference 2) const parameters to pure functions are passed by reference, if and only if all other parameters - including any implicit this parameter - contain no mutable

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 23:19:18 UTC, John Colvin wrote: On Monday, 7 November 2016 at 22:46:57 UTC, Stefan Koch wrote: On Monday, 7 November 2016 at 21:45:42 UTC, John Colvin wrote: On Monday, 7 November 2016 at 20:23:37 UTC, Jacob Carlborg wrote: Since D is a systems programming languag

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 22:46:57 UTC, Stefan Koch wrote: On Monday, 7 November 2016 at 21:45:42 UTC, John Colvin wrote: On Monday, 7 November 2016 at 20:23:37 UTC, Jacob Carlborg wrote: Since D is a systems programming language, wouldn't the user want to have control over this? It's jus

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 21:45:42 UTC, John Colvin wrote: On Monday, 7 November 2016 at 20:23:37 UTC, Jacob Carlborg wrote: Since D is a systems programming language, wouldn't the user want to have control over this? It's just another optimisation in a long list of optimisations that can

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 20:23:37 UTC, Jacob Carlborg wrote: Since D is a systems programming language, wouldn't the user want to have control over this? It's just another optimisation in a long list of optimisations that can be performed without changing semantics. What about this one i

Re: calling convention optimisation & const/immutable ref

otherwise be copied and passed on the stack: 1) immutable parameters to all functions are passed by reference 2) const parameters to pure functions are passed by reference, if and only if all other parameters - including any implicit this parameter - contain no mutable references (otherwise "w

calling convention optimisation & const/immutable ref

stack: 1) immutable parameters to all functions are passed by reference 2) const parameters to pure functions are passed by reference, if and only if all other parameters - including any implicit this parameter - contain no mutable references (otherwise "weakly" pure functions could

Re: GC of const/immutable reference graphs

On 9/13/16 11:27 AM, John Colvin wrote: For the following, lifetimeEnd(x) is the time of freeing of x. Given a reference graph and an const/immutable node n, all nodes reachable via n (let's call them Q(n)) must also be const/immutable, as per the rules of D's type system. In orde

Re: GC of const/immutable reference graphs

On Tuesday, 13 September 2016 at 15:27:23 UTC, John Colvin wrote: For the following, lifetimeEnd(x) is the time of freeing of x. Given a reference graph and an const/immutable node n, all nodes reachable via n (let's call them Q(n)) must also be const/immutable, as per the rules of D&#

GC of const/immutable reference graphs

For the following, lifetimeEnd(x) is the time of freeing of x. Given a reference graph and an const/immutable node n, all nodes reachable via n (let's call them Q(n)) must also be const/immutable, as per the rules of D's type system. In order to avoid dangling pointers: For al

Re: typeid() on class instances discards immutable

On 25.07.2016 17:48, Cauterite wrote: I noticed that for some class `T`, `typeid(new immutable(T)) != typeid(immutable(T))`. The immutability is lost in the object's typeinfo, but retained in the class's typeinfo. See: https://dpaste.dzfl.pl/f04d41ff2986 Is this intended behaviour o

typeid() on class instances discards immutable

I noticed that for some class `T`, `typeid(new immutable(T)) != typeid(immutable(T))`. The immutability is lost in the object's typeinfo, but retained in the class's typeinfo. See: https://dpaste.dzfl.pl/f04d41ff2986 Is this intended behaviour or a bug? I couldn't find any me

Re: An important pull request: accessing shared affix for immutable data

Am Sat, 13 Feb 2016 19:16:43 +0100 schrieb Timon Gehr : > Not necessarily. shared is transitive and prefix/suffix are arbitrary > types which might contain mutable indirections. I don't want to disturb your conversation, but how about designing a working "shared" first? My last attempt at using

Re: An important pull request: accessing shared affix for immutable data

On 02/12/2016 02:12 PM, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/3991 Finally I got around to update this. Please find holes in my logic. Updated documentation at: http://dtest.thecybershadow.net/artifact/website-6a8825cc07dee2db751fa4b61044073b228c20c

Re: sorting a mutable array of immutable objects

On Wednesday, 20 April 2016 at 12:34:28 UTC, Anonymouse wrote: On Wednesday, 20 April 2016 at 10:32:42 UTC, Jeff Thompson wrote: On Wednesday, 20 April 2016 at 09:54:13 UTC, Jeff Thompson wrote: I can create a mutable array of immutable objects, thanks to the answers to my other question

Re: sorting a mutable array of immutable objects

On Wednesday, 20 April 2016 at 12:34:28 UTC, Anonymouse wrote: On Wednesday, 20 April 2016 at 10:32:42 UTC, Jeff Thompson [...] Also note that sort (std.algorithm.sorting : sort) returns a range and doesn't sort in place. (Lastly this is probably more at home in the Learn forum.) It does sor

Re: sorting a mutable array of immutable objects

On Wednesday, 20 April 2016 at 10:32:42 UTC, Jeff Thompson wrote: On Wednesday, 20 April 2016 at 09:54:13 UTC, Jeff Thompson wrote: I can create a mutable array of immutable objects, thanks to the answers to my other question https://forum.dlang.org/post/nf57f5$e6v$1...@digitalmars.com . Now

Re: sorting a mutable array of immutable objects

On Wednesday, 20 April 2016 at 09:54:13 UTC, Jeff Thompson wrote: I can create a mutable array of immutable objects, thanks to the answers to my other question https://forum.dlang.org/post/nf57f5$e6v$1...@digitalmars.com . Now I want to sort the array. I found a solution, but I'm not

Re: sorting a mutable array of immutable objects

On Wednesday, 20 April 2016 at 09:54:13 UTC, Jeff Thompson wrote: I can create a mutable array of immutable objects, thanks to the answers to my other question https://forum.dlang.org/post/nf57f5$e6v$1...@digitalmars.com . Now I want to sort the array, but the sort function doesn't &quo

sorting a mutable array of immutable objects

I can create a mutable array of immutable objects, thanks to the answers to my other question https://forum.dlang.org/post/nf57f5$e6v$1...@digitalmars.com . Now I want to sort the array, but the sort function doesn't "see" the opCmp in class C. Do I need to define a custom co

Re: mutable array of immutable objects

On 19.04.2016 14:07, Jeff Thompson wrote: On Tuesday, 19 April 2016 at 11:43:22 UTC, Anonymouse wrote: On Tuesday, 19 April 2016 at 10:41:05 UTC, Jeff Thompson wrote: I want to create a mutable array of immutable objects, but the code below gives the error shown below. It seems that &quo

Re: mutable array of immutable objects

Am 19.04.2016 um 12:41 schrieb Jeff Thompson: I want to create a mutable array of immutable objects, but the code below gives the error shown below. It seems that "new immutable(C)[1]" makes the entire array immutable, but it seems I should be able to change the elements of an array o

Re: mutable array of immutable objects

On Tuesday, 19 April 2016 at 11:43:22 UTC, Anonymouse wrote: On Tuesday, 19 April 2016 at 10:41:05 UTC, Jeff Thompson wrote: I want to create a mutable array of immutable objects, but the code below gives the error shown below. It seems that "new immutable(C)[1]" makes the en

Re: mutable array of immutable objects

On Tuesday, 19 April 2016 at 10:41:05 UTC, Jeff Thompson wrote: I want to create a mutable array of immutable objects, but the code below gives the error shown below. It seems that "new immutable(C)[1]" makes the entire array immutable, but it seems I should be able to change the e

mutable array of immutable objects

I want to create a mutable array of immutable objects, but the code below gives the error shown below. It seems that "new immutable(C)[1]" makes the entire array immutable, but it seems I should be able to change the elements of an array of pointers to an object even though the o

Re: Synchronization on immutable object

`try { throw new immutable Exception; } catch(Exception) { }` and plenty of array appending bugs have been fixed in the past. Thanks. Gives some confidence in the correctness of https://github.com/D-Programming-Language/dmd/pull/5564

Re: Synchronization on immutable object

On 03/22/2016 12:49 PM, Johan Engelen wrote: > Quiz: does this compile or not? tl; dr: most of druntime internal functions bypass qualifiers and are constant source of type system violation bugs. There is a similar violation with `try { throw new immutable Exception; } catch(Exception) { }`

Re: Synchronization on immutable object

g out of your way to access the internal __monitor field). Internally, the compiler breaks a language guarantee: it allows passing an immutable Object to a function as mutable argument. The synchronization object is passed to _d_monitorenter in druntime. An optimizer may use the immutability inf

Re: Synchronization on immutable object

On Tuesday, 22 March 2016 at 10:49:01 UTC, Johan Engelen wrote: Quiz: does this compile or not? ``` class Klass {} void main() { immutable Klass klass = new Klass; synchronized (klass) { // do smth } } ``` A D object contains two (!) hidden pointers. Two? Yes: the

Re: Synchronization on immutable object

Related bug report: https://issues.dlang.org/show_bug.cgi?id=14251

Synchronization on immutable object

Quiz: does this compile or not? ``` class Klass {} void main() { immutable Klass klass = new Klass; synchronized (klass) { // do smth } } ``` A D object contains two (!) hidden pointers. Two? Yes: the vtable pointer __vptr, and a pointer to a Monitor struct which

Re: Clojure vs. D in creating immutable lists that are almost the same.

On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques to use functional programming, without massive copying of

Re: Clojure vs. D in creating immutable lists that are almost the same.

On Sat, 27 Feb 2016 22:31:28 +, Brother Bill wrote: > Clojure supports immutable lists that allow adding and removing > elements, and yet still have excellent performance. > > For D language, what are the recommended techniques to use functional > programming, without massive

Re: Clojure vs. D in creating immutable lists that are almost the same.

On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: That is, how to create one-off changes to an immutable data structure, while keeping the original immutable, as well as the one-off change, and maintain good performance. Clojure uses bit-partitioned hash tries. I

Re: Clojure vs. D in creating immutable lists that are almost the same.

On Saturday, 27 February 2016 at 23:19:51 UTC, w0rp wrote: On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques

Re: Clojure vs. D in creating immutable lists that are almost the same.

On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques to use functional programming, without massive copying of

Clojure vs. D in creating immutable lists that are almost the same.

Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques to use functional programming, without massive copying of data and garbage collection, so that it remains immutable. That

Re: constructing module level immutable variables at runtime?

On 2/22/16 9:58 AM, Danni Coy via Digitalmars-d wrote: That worked however it seems that you can only do the assignments within the shared static this() and not from functions called by the initialiser which might change how I do things This is true. The compiler wants to be super-sure that yo

Re: constructing module level immutable variables at runtime?

That worked however it seems that you can only do the assignments within the shared static this() and not from functions called by the initialiser which might change how I do things

Re: constructing module level immutable variables at runtime?

On 2/22/16 2:36 AM, Danni Coy via Digitalmars-d wrote: On Mon, Feb 22, 2016 at 5:29 PM, Sönke Ludwig wrote: I was wrong, there is obviously a language/compiler bug here. It compiles if you remove the "= void", but it does so for "shared static this" as well as for "static this". It really shoul

Re: constructing module level immutable variables at runtime?

On Mon, Feb 22, 2016 at 5:29 PM, Sönke Ludwig wrote: > I was wrong, there is obviously a language/compiler bug here. It compiles if > you remove the "= void", but it does so for "shared static this" as well as > for "static this". It really shouldn't in the latter case. Interesting... It definate

Re: constructing module level immutable variables at runtime?

alue of num_triggers, potentially multiple times. module config; shared static this () { num_triggers = 1024; } private: immutable(int) num_triggers = void; is not working for me with dmd 2.070 I was wrong, there is obviously a language/compiler bug here. It compiles if you remove the &

Re: constructing module level immutable variables at runtime?

e times. module config; shared static this () { num_triggers = 1024; } private: immutable(int) num_triggers = void; is not working for me with dmd 2.070

Re: constructing module level immutable variables at runtime?

On Mon, Feb 22, 2016 at 5:14 PM, Ali Çehreli wrote: > There is import() to read a config file at compile time: In my case the config files are there to allow end users to tune the application - therefore config files need to be read at runtime.

Re: constructing module level immutable variables at runtime?

. module config; static this() { num_triggers = to!int(getValueFromConfigFile()); } private: immutable(int) num_triggers = void; Is there any reason that allowing this would be a bad idea? There is import() to read a config file at compile time: module config; string

Re: constructing module level immutable variables at runtime?

. module config; static this() { num_triggers = to!int(getValueFromConfigFile()); } private: immutable(int) num_triggers = void; Is there any reason that allowing this would be a bad idea? This actually works already, if you use "shared static this". "static this"

constructing module level immutable variables at runtime?

(getValueFromConfigFile()); } private: immutable(int) num_triggers = void; Is there any reason that allowing this would be a bad idea?

Re: An important pull request: accessing shared affix for immutable data

On Sunday, 14 February 2016 at 11:14:59 UTC, Andrei Alexandrescu wrote: We can do the same, but we also have a better alternative. Most of our allocators support shrink-in-place. For now I haven't exposed it as a primitive but that's short work. When the object goes away we can shrink memory in

Re: An important pull request: accessing shared affix for immutable data

On 02/14/2016 03:08 AM, Sönke Ludwig wrote: For them to work natively, the lifetime of the allocated memory block and that of the reference count must be separate. Not necessarily. C++ makes this work for make_shared by keeping the memory allocated around (but not the object) until the last we

Re: An important pull request: accessing shared affix for immutable data

One thing that I really miss from most of the discussions about RC is support for weak references, which IMO should definitely be supported in the standard RC implementation. Event if they are only needed rarely, there are some things that simply do not work without them. And I don't think they

Re: An important pull request: accessing shared affix for immutable data

On Sunday, 14 February 2016 at 01:27:40 UTC, Andrei Alexandrescu wrote: On 2/13/16 5:01 PM, deadalnix wrote: What about storing the metadata at an address that is computable from from the object's address, while not being contiguous with the object allocated ? Is substracting a constant really

Re: An important pull request: accessing shared affix for immutable data

On 2/13/16 5:01 PM, deadalnix wrote: What about storing the metadata at an address that is computable from from the object's address, while not being contiguous with the object allocated ? Is substracting a constant really the only option here ? (hint, it is not) I'd say, you have at your dispo

Re: An important pull request: accessing shared affix for immutable data

On 02/13/2016 04:34 AM, Andrei Alexandrescu wrote: > On 02/12/2016 08:42 PM, Dicebot wrote: >> So you >> envision this kind of metadata support to be only available via specific >> type of allocator, AffixAllocator, and not being supported by most of >> them? > > That is correct. You want metadata

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 22:01:45 UTC, deadalnix wrote: On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: There's no need. I'll do the implementation with the prefix, and if you do it with a global hashtable within the same or better speed, my hat is off to you.

Re: An important pull request: accessing shared affix for immutable data

balAllocator; // assign mutable to immutable private void[] data; ~this () { allocator.decRef(data.ptr); } }

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 22:16:02 UTC, rsw0x wrote: On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote: [...] There's no need. I'll do the implementation with the prefix, and if you do it with a globa

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote: 2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d >: https://github.com/D-Programming-Language/phobos/p

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: There's no need. I'll do the implementation with the prefix, and if you do it with a global hashtable within the same or better speed, my hat is off to you. That is false dichotomy. What about storing the metadata at a

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 13:10:19 UTC, Andrei Alexandrescu wrote: On 2/13/16 7:40 AM, John Colvin wrote: On Saturday, 13 February 2016 at 00:30:58 UTC, Andrei Alexandrescu wrote: On 02/12/2016 06:52 PM, deadalnix wrote: [...] I think we're good there. -- Andrei Is there somewhere w

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 21:49:48 UTC, ZombineDev wrote: On Saturday, 13 February 2016 at 02:35:43 UTC, Andrei Alexandrescu wrote: On 02/12/2016 09:21 PM, Timon Gehr wrote: Const could also mean mutable. This can hence reference the same data as both shared and unshared, which violates

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 02:35:43 UTC, Andrei Alexandrescu wrote: On 02/12/2016 09:21 PM, Timon Gehr wrote: Const could also mean mutable. This can hence reference the same data as both shared and unshared, which violates the type system. If const comes from mutable, then shared is su

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 21:38:30 UTC, ZombineDev wrote: ... get non-shared references in to it (and vice-versa - you should have shared references in a non-shared objects). ... you should ***not be able to*** have shared references in a non-shared objects

Re: An important pull request: accessing shared affix for immutable data

system already relies on the allocators and putting more trust in them can indeed enable some interesting opportunities. So after thinking a bit I managed to convince myself that the affixes in an AffixAllocator can be accessed with removing immutable, but without actually breaking any guarant

Re: An important pull request: accessing shared affix for immutable data

On 02/13/2016 03:07 PM, Iakh wrote: So you can use metadata only with global allocators, until you don't need to save ref to the allocator. Well you can use other allocators if you save them so you have them available for deallocation. -- Andrei

Re: An important pull request: accessing shared affix for immutable data

On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote: 2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d mailto:digitalmars-d@puremagic.com>>: https://github.com/D-Programming-Language/phobos/pull/3991 The only difference between an approach based on an associative

Re: An important pull request: accessing shared affix for immutable data

llocator. Why can't we use attribute @intransitive on ref fields to prevents immutable being transitively applied on referred content? Add some restrictions (only private, wrap using with trusted) and it would be enough to implement RefCounting with immutable.

Re: An important pull request: accessing shared affix for immutable data

2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>: > https://github.com/D-Programming-Language/phobos/pull/3991 > The only difference between an approach based on an associative array and > AffixAllocator is that the latter is faster (the association

Re: An important pull request: accessing shared affix for immutable data

On Friday, 12 February 2016 at 23:29:58 UTC, Timon Gehr wrote: The first thing that comes to mind is that accessing a global associative array is not 'pure'. Not necessarily. Purity depends on the allocator and how you access it (via parameter or through a static/shared instance). I have this

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 18:16:43 UTC, Timon Gehr wrote: On 13.02.2016 18:42, Andrei Alexandrescu wrote: On 02/13/2016 11:55 AM, Timon Gehr wrote: If you alias the same data as both shared and unshared, the shared version can be sent to another thread which will then modify it, violat

  1   2   3   4   5   6   7   8   9   10   >