[Issue 16538] Parameter head-const-ness shouldn't matter but does

https://issues.dlang.org/show_bug.cgi?id=16538 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 23034] importC: head-const struct confused with multiple files on command line

|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #14016 "fix Issue 23034 - importC: head-const struct confused with multiple f…" was merged into master: - 62c0846dd48cef8cf032a552c3e43c18565c42ea by Walter Bright: fix Issue 23034 - importC: head-const struc

[Issue 23034] importC: head-const struct confused with multiple files on command line

https://issues.dlang.org/show_bug.cgi?id=23034 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh

[Issue 23034] importC: head-const struct confused with multiple files on command line

--- @WalterBright created dlang/dmd pull request #14016 "fix Issue 23034 - importC: head-const struct confused with multiple f…" fixing this issue: - fix Issue 23034 - importC: head-const struct confused with multiple files on command line https://github.com/dlang/dmd/pull/14016 --

[Issue 23034] importC: head-const struct confused with multiple files on command line

https://issues.dlang.org/show_bug.cgi?id=23034 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1

[Issue 23034] New: importC: head-const struct confused with multiple files on command line

https://issues.dlang.org/show_bug.cgi?id=23034 Issue ID: 23034 Summary: importC: head-const struct confused with multiple files on command line Product: D Version: D2 Hardware: All OS: All Status

[Issue 16538] Parameter head-const-ness shouldn't matter but does

https://issues.dlang.org/show_bug.cgi?id=16538 --- Comment #2 from Walter Bright --- Fixed by https://github.com/dlang/dmd/pull/6731 --

[Issue 16538] Parameter head-const-ness shouldn't matter but does

https://issues.dlang.org/show_bug.cgi?id=16538 Walter Bright changed: What|Removed |Added CC|

[Issue 13796] A simple "array head const" struct for Phobos

https://issues.dlang.org/show_bug.cgi?id=13796 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/415d573a3c8688396f0f46643bd1fedc923620dc Add std.experimental.typecons.HeadConst - fix issue

[Issue 16538] New: Parameter head-const-ness shouldn't matter but does

https://issues.dlang.org/show_bug.cgi?id=16538 Issue ID: 16538 Summary: Parameter head-const-ness shouldn't matter but does Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity

[Issue 13796] A simple "array head const" struct for Phobos

https://issues.dlang.org/show_bug.cgi?id=13796 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/415d573a3c8688396f0f46643bd1fedc923620dc Add std.experimental.typecons.HeadConst - fix issue

[Issue 13796] A simple "array head const" struct for Phobos

https://issues.dlang.org/show_bug.cgi?id=13796 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: Head Const

On Wednesday, 24 February 2016 at 19:28:28 UTC, extrawurst wrote: On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: [...] I think that increasing language complexity for the sake of C++ integration is a

Re: Head Const

On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const

Re: Head Const

On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses

Re: Head Const

On Friday, 19 February 2016 at 21:53:16 UTC, Walter Bright wrote: On 2/19/2016 4:38 AM, Jonathan M Davis wrote: Why not? I would expect the opaque type to have to have it too, e.g. @mutable struct S; That would mean you're proposing '@mutable const' as a type constructor, which you'd

Re: Head Const

On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote: Allow @mutable, and no more mechanical checking in D. Recall that D supports opaque types, meaning types are not fully known to the compiler. Allow @trusted, an no more mechanical checking in D. Recall that D supports extern

Re: Head Const

On Friday, 19 February 2016 at 00:45:00 UTC, Walter Bright wrote: On 2/18/2016 6:04 AM, Marc Schütz wrote: Rule 2 only forbids _static immutables_ with @mutable members, precisely because those could end up in read-only memory. I don't see how allocators are affected at all. An allocator would

Re: Head Const

On Friday, 19 February 2016 at 21:53:16 UTC, Walter Bright wrote: On 2/19/2016 4:38 AM, Jonathan M Davis wrote: Yes, as long as you have the source code, finding @trusted violations is _way_ easier in D than it is in C++, but the fact that it's possible to cast away const and mutate still

Re: Head Const

On 02/19/2016 05:04 PM, Chris Wright wrote: In other words, it works fine if you have a ref-counted string. It works fine if you have a ref-counted list of ref-counted strings. But that list *must* be mutable. Much simpler - direct membership. The first thing people want to do when you give

Re: Head Const

On Fri, 19 Feb 2016 16:09:21 -0500, Andrei Alexandrescu wrote: > On 02/19/2016 03:46 PM, Iakh wrote: >> On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright wrote: >>> On 2/18/2016 10:22 AM, Timon Gehr wrote: He wanted to embed a mutable reference count literally within a const

Re: Head Const

On 2/19/2016 4:38 AM, Jonathan M Davis wrote: Yes, as long as you have the source code, finding @trusted violations is _way_ easier in D than it is in C++, but the fact that it's possible to cast away const and mutate still means that the compiler can't actually guarantee that an object is not

Re: Head Const

On 02/19/2016 03:46 PM, Iakh wrote: On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright wrote: On 2/18/2016 10:22 AM, Timon Gehr wrote: He wanted to embed a mutable reference count literally within a const object. Not a headconst object. I know. I pointed out how it could be done in

Re: Head Const

On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright wrote: On 2/18/2016 10:22 AM, Timon Gehr wrote: He wanted to embed a mutable reference count literally within a const object. Not a headconst object. I know. I pointed out how it could be done in a way to achieve the same effect.

Re: Head Const

On Friday, 19 February 2016 at 12:03:01 UTC, Walter Bright wrote: On 2/19/2016 3:21 AM, Jonathan M Davis wrote: D is definitely in a better boat in that it's easier to find and catch problems with const, but it really doesn't do much more to actually guarantee that a const object isn't being

Re: Head Const

On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) If it's for mangling, there can be lightweight pragma for individual parameters:

Re: Head Const

On 2/19/2016 3:21 AM, Jonathan M Davis wrote: D is definitely in a better boat in that it's easier to find and catch problems with const, but it really doesn't do much more to actually guarantee that a const object isn't being violated. Programmers are free to do horrible things and mark it as

Re: Head Const

On Friday, 19 February 2016 at 10:03:44 UTC, Walter Bright wrote: On 2/18/2016 11:46 PM, Jonathan M Davis wrote: We're in exactly the same boat as C++ in that we rely on the programmer to be smart about casting away const in order for const to provide any guarantees. No, we're not. @trusted

Re: Head Const

On 2/18/2016 11:46 PM, Jonathan M Davis wrote: We're in exactly the same boat as C++ in that we rely on the programmer to be smart about casting away const in order for const to provide any guarantees. No, we're not. @trusted is specifically designed to be greppable (so are casts, by the

Re: Head Const

On Friday, 19 February 2016 at 08:51:26 UTC, Shachar Shemesh wrote: The way I see it, here's how it is with C++: Get const pointer. Cast away its constness. If the original data was mutable, you're gold. If not, undefined behaviour. Yes, and since interpret_cast<> seems to not accept casting

Re: Head Const

On 17/02/16 14:03, Jakob Ovrum wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy

Re: Head Const

On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote: On 2/18/2016 9:46 PM, Jonathan M Davis wrote: On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright wrote: On 2/18/2016 4:16 AM, Jonathan M Davis wrote: headconst may solve the extern(C++) problem, but it really doesn't

Re: Head Const

On 2/18/2016 9:46 PM, Jonathan M Davis wrote: On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright wrote: On 2/18/2016 4:16 AM, Jonathan M Davis wrote: headconst may solve the extern(C++) problem, but it really doesn't solve the problems we have with const. 'mutable' doesn't really

Re: Head Const

On Friday, 19 February 2016 at 05:33:54 UTC, Doc wrote: On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis wrote: The more I look at it, the more I'm inclined to think that introducing @mutable for member variables with a corresponding, required attribute on the struct or

Re: Head Const

On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright wrote: On 2/18/2016 4:16 AM, Jonathan M Davis wrote: headconst may solve the extern(C++) problem, but it really doesn't solve the problems we have with const. 'mutable' doesn't really solve a problem, it just means that C++

Re: Head Const

On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis wrote: The more I look at it, the more I'm inclined to think that introducing @mutable for member variables with a corresponding, required attribute on the struct or class it's in (e.g. @has_mutable) is really what we need to

Re: Head Const

On 2/18/2016 6:04 AM, Marc Schütz wrote: Rule 2 only forbids _static immutables_ with @mutable members, precisely because those could end up in read-only memory. I don't see how allocators are affected at all. An allocator would be mutable, or at least manage mutable memory. You could create a

Re: Head Const

On Thursday, 18 February 2016 at 22:48:01 UTC, Walter Bright wrote: struct A { int* pi; } and *pi will be mutable even though pi is __const. Here's the big deal: when you have started on an implementation with constness in, and then evolve the codebase and have to turn some fields mutable

Re: Head Const

On 2/18/2016 4:18 AM, Andrei Alexandrescu wrote: On 02/17/2016 05:44 PM, Walter Bright wrote: It would seem that implementing headconst as a type constructor would let people who wanted mutable members have their way, without introducing backdoors in const. Doesn't seem that way to me, viz:

Re: Head Const

On 2/18/2016 10:22 AM, Timon Gehr wrote: He wanted to embed a mutable reference count literally within a const object. Not a headconst object. I know. I pointed out how it could be done in a way to achieve the same effect. BTW, shared_ptr<> uses a pointer to the ref count.

Re: Head Const

On 2/18/2016 4:16 AM, Jonathan M Davis wrote: headconst may solve the extern(C++) problem, but it really doesn't solve the problems we have with const. 'mutable' doesn't really solve a problem, it just means that C++ 'const' is a documentation aid, not a guarantee.

Re: Head Const

On 18.02.2016 13:03, Walter Bright wrote: On 2/18/2016 2:47 AM, Timon Gehr wrote: On 18.02.2016 10:24, Walter Bright wrote: On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes? Jonathan wanted to embed a mutable reference count within a const

Re: Head Const

On Thursday, 18 February 2016 at 14:58:00 UTC, ixid wrote: On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis wrote: The problem that folks frequently want to be able to solve that they simply cannot solve >with D's const (and headconst wouldn't help) is that they want to be able

Re: Head Const

On Thursday, 18 February 2016 at 14:58:00 UTC, ixid wrote: Is it not possible to have two objects, the data and the information about the data? It seems like a mistake to try to Not if the immutability is transitive. But "struct" isn't really an object, it is a chunk of memory. Often an

Re: Head Const

On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis wrote: The problem that folks frequently want to be able to solve that they simply cannot solve >with D's const (and headconst wouldn't help) is that they want to be able to pass an object >to a function that takes it as const or

Re: Head Const

On Thursday, 18 February 2016 at 11:12:40 UTC, Dicebot wrote: On 02/17/2016 08:48 PM, Marc Schütz wrote: On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote: One example of a existing guarantee you won't be able to keep, for example, is that any immutable allocation can be

Re: Head Const

On Thursday, 18 February 2016 at 11:20:53 UTC, Dicebot wrote: Consider "static if is fundamentally flawed" vs "static if is fundamentally flawed [when applied to existing idiomatic C++ code]". Former is opinionated prejudice. Latter can quite easily be true (even if I personally wouldn't agree

Re: Head Const

On 02/17/2016 06:47 PM, Walter Bright wrote: If the headconst was one level up, the struct can have mutating members. That's not headconst. It's hairconst. -- Andrei

Re: Head Const

On 02/17/2016 05:44 PM, Walter Bright wrote: It would seem that implementing headconst as a type constructor would let people who wanted mutable members have their way, without introducing backdoors in const. Doesn't seem that way to me, viz: struct A { int i; } A __const(A) will have a

Re: Head Const

On Thursday, 18 February 2016 at 12:03:00 UTC, Walter Bright wrote: On 2/18/2016 2:47 AM, Timon Gehr wrote: On 18.02.2016 10:24, Walter Bright wrote: On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes? Jonathan wanted to embed a mutable

Re: Head Const

On 2/18/2016 2:47 AM, Timon Gehr wrote: On 18.02.2016 10:24, Walter Bright wrote: On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes? Jonathan wanted to embed a mutable reference count within a const object. Contrary to your suggestion,

Re: Head Const

On Thursday, 18 February 2016 at 10:47:57 UTC, Timon Gehr wrote: On 18.02.2016 10:24, Walter Bright wrote: On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes? Jonathan wanted to embed a mutable reference count within a const object. Contrary

Re: Head Const

On 02/17/2016 01:53 PM, Andrei Alexandrescu wrote: > On 02/16/2016 09:44 PM, Walter Bright wrote: >> On 2/16/2016 5:35 AM, Dicebot wrote: >>> In my opinion @mutable would be a disaster of much higher destructive >>> impact than head const. I am very opposed to it no ma

Re: Head Const

On 02/17/2016 08:48 PM, Marc Schütz wrote: > On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote: >> One example of a existing guarantee you won't be able to keep, for >> example, is that any immutable allocation can be completely put into >> separate read-only memory. > > Yes, and it

Re: Head Const

On Thursday, 18 February 2016 at 06:49:34 UTC, Daniel Murphy wrote: It's not macroish string processing, it's embedding a subset of C++ declarations like a DSL. The difference is that the C++ can be fully type-checked and semantically analysed, errors will not leak into the generated source.

Re: Head Const

On 18.02.2016 10:24, Walter Bright wrote: On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes? Jonathan wanted to embed a mutable reference count within a const object. Contrary to your suggestion, headconst won't help with that.

Re: Head Const

On 2/17/2016 11:58 PM, Timon Gehr wrote: const(headconst(T)) is the same as const(T), no? Er, yes?

Re: Head Const

On Wednesday, 17 February 2016 at 22:01:45 UTC, Walter Bright wrote: On 2/17/2016 4:03 AM, Jakob Ovrum wrote: How about disallowing immutable data with extern(C++) types? With extern(C++) data always mutable, `const` could safely be reused to mean C++ const in bindings. Any `mutable`-style

Re: Head Const

Too illustrate how headconst can help with multithreading (shared memory) code, I have created this small snippet. In my experience, there are lots of *effectively immutable* objects (like Foo.bar in the code snippet). If these variables can be declared headconst, a lot of hierarchical

Re: Head Const

On 18.02.2016 08:51, Walter Bright wrote: On 2/17/2016 4:41 PM, Jonathan M Davis wrote: Yes, but that really isn't going to help much code. It would be useless for ref-counting const objects, it wouldn't allow you to put a mutex in a const object, and you couldn't do anything with caching

Re: Head Const

On 2/17/2016 4:41 PM, Jonathan M Davis wrote: Yes, but that really isn't going to help much code. It would be useless for ref-counting const objects, it wouldn't allow you to put a mutex in a const object, and you couldn't do anything with caching calculated properties in a const object. Embed

Re: Head Const

On 2/17/2016 2:38 PM, Andrei Alexandrescu wrote: On 02/17/2016 04:07 PM, Walter Bright wrote: On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote: On 02/16/2016 09:53 PM, Walter Bright wrote: Most of what people find frustrating about D's transitive const/immutable is its very nature of not being

Re: Head Const

Greetings Having coded a multithreaded library in D, I sorely miss headcost like specifier. The library code dealt with lots of composite class object hierarchy where many element objects of a parent are *effectively immutable*. You build an effectively immutable object in the constructor

Re: Head Const

On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis wrote: On Wednesday, 17 February 2016 at 17 you're not actually getting. But in practice, it does prevent accidental mutation, and as long as the programmer is behaving themselves reasonably well, Unfortunately, the net

Re: Head Const

On 16/02/2016 8:29 PM, Ola Fosheim Grøstad wrote: I agree with the principle, but not as a library function, because: 1. you want virtual functions to work out ok virtual functions don't even need mangling. But even if they did it would work just fine anyway. 2. making D more reliant

Re: Head Const

about the lack of head-const. And what's usually the case is that folks want logical const, and I don't see how that's possible without either having something similar to C++'s mutable or make it well-defined to cast away const and mutate. Having something similar to C++'s mutable would

Re: Head Const

On 2/17/2016 3:12 PM, Jonathan M Davis wrote: On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright wrote: It would seem that implementing headconst as a type constructor would let people who wanted mutable members have their way, without introducing backdoors in const. I really

Re: Head Const

On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright wrote: It would seem that implementing headconst as a type constructor would let people who wanted mutable members have their way, without introducing backdoors in const. I really don't see how that's the same thing at all. The

Re: Head Const

On 2/17/2016 2:31 PM, Jonathan M Davis wrote: We _could_ have something like @mutable on member variables which made them mutable in spite of being in a const object and which made it illegal for that type to ever be immutable, but we'd be forced to have an additional attribute on the type

Re: Head Const

On 02/17/2016 04:07 PM, Walter Bright wrote: On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote: On 02/16/2016 09:53 PM, Walter Bright wrote: Most of what people find frustrating about D's transitive const/immutable is its very nature of not being sloppy and full of holes. I thought it was the

Re: Head Const

On Wednesday, 17 February 2016 at 22:06:20 UTC, Walter Bright wrote: On 2/17/2016 10:54 AM, Marc Schütz wrote: That's already covered in the DIP, see my reply to Dicebot. Note that D supports opaque types, meaning it is not always possible to transitively follow all types to see if they have

Re: Head Const

On 2/17/2016 10:54 AM, Marc Schütz wrote: That's already covered in the DIP, see my reply to Dicebot. Note that D supports opaque types, meaning it is not always possible to transitively follow all types to see if they have mutable members.

Re: Head Const

On 2/17/2016 4:03 AM, Jakob Ovrum wrote: How about disallowing immutable data with extern(C++) types? With extern(C++) data always mutable, `const` could safely be reused to mean C++ const in bindings. Any `mutable`-style code would be implemented in C++. That doesn't help with trying to match

Re: Head Const

On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote: On 02/16/2016 09:53 PM, Walter Bright wrote: Most of what people find frustrating about D's transitive const/immutable is its very nature of not being sloppy and full of holes. I thought it was the constructors and postblit that are the matter.

Re: Head Const

On Wednesday, 17 February 2016 at 19:03:25 UTC, Jonathan M Davis wrote: As soon as you start using pointers or containers or pointers or anything like that, pretty quickly, you can get situations like where the container is const, but its elements aren't. Yes, generic containers is an issue

Re: Head Const

On Wednesday, 17 February 2016 at 18:16:54 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis wrote: definitely sucks. But interestingly, the more I've used D, the less happy I've been with C++'s const. It just has too many holes. In particular,

Re: Head Const

On Wednesday, 17 February 2016 at 02:51:06 UTC, Walter Bright wrote: On 2/16/2016 11:29 AM, Marc Schütz wrote: For example, it's always possible to use a global mutable associative array to store additional data connected with an immutable or const object (ignoring purity issues for the

Re: Head Const

On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote: One example of a existing guarantee you won't be able to keep, for example, is that any immutable allocation can be completely put into separate read-only memory. Yes, and it would be rejected statically (rule 2). I therefor

Re: Head Const

On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis wrote: definitely sucks. But interestingly, the more I've used D, the less happy I've been with C++'s const. It just has too many holes. In particular, the fact that it's not transitive is What you could consider in C++ is to

Re: Head Const

On Wednesday, 17 February 2016 at 17:25:40 UTC, rsw0x wrote: It's weird because usually D prefers the practical solution over the ivory tower one. Nearly every time I end up using immutable or const for anything beyond say, a trivial function parameter, I always end up removing it. My C++ code

Re: Head Const

On Tuesday, 16 February 2016 at 10:31:05 UTC, Guillaume Piolat wrote: On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright wrote: 2. supports single assignment style of programming, even if the data is otherwise mutable Like 'final'? We did get rid of that... Maybe we should

Re: Head Const

inish line. Between not being able to have head const, needing to mutate vars in a const object (a la refcount) and the compiler deciding functions are pure, I often end up facing a problem where I say "okay, forget it". And that's a real shame. We have at least one case where we're

Re: Head Const

On Wednesday, 17 February 2016 at 12:46:08 UTC, Jonathan M Davis wrote: but violate the type system by casting away const and mutating, not realizing that unlike C++, it's undefined behavior in D. Regardless of whether Walter's (and thus D's) stance on const is the right one, it clearly

Re: Head Const

On Wednesday, 17 February 2016 at 11:56:29 UTC, Andrei Alexandrescu wrote: On 02/16/2016 09:53 PM, Walter Bright wrote: Most of what people find frustrating about D's transitive const/immutable is its very nature of not being sloppy and full of holes. I thought it was the constructors and

Re: Head Const

On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses

Re: Head Const

On 02/16/2016 09:53 PM, Walter Bright wrote: Most of what people find frustrating about D's transitive const/immutable is its very nature of not being sloppy and full of holes. I thought it was the constructors and postblit that are the matter. (It may seem I'm on a snarky streak, but I do

Re: Head Const

On 02/16/2016 09:51 PM, Walter Bright wrote: On 2/16/2016 11:29 AM, Marc Schütz wrote: For example, it's always possible to use a global mutable associative array to store additional data connected with an immutable or const object (ignoring purity issues for the moment). That's safe because

Re: Head Const

On 02/16/2016 09:44 PM, Walter Bright wrote: On 2/16/2016 5:35 AM, Dicebot wrote: In my opinion @mutable would be a disaster of much higher destructive impact than head const. I am very opposed to it no matter how it is designed. Once you start considering it, you are better at simply throwing

Re: Head Const

On 2/16/2016 9:56 PM, Ola Fosheim Grøstad wrote: 1. The compiler has access to all reachable types. Nope. Opaque types are supported.

Re: Head Const

constness / immutability in third party libraries to get around the limitations. C++ added "mutable" keyword for a reason... with head const which is much less limiting to begin with... Furthermore, with the current mechanical guarantee of immutability, it opens up the po

Re: Head Const

On 02/17/2016 04:44 AM, Walter Bright wrote: > Note that head const does not introduce any watering down nor > destruction of the const/immutable/sharing type system. The main > downside of head const would be language complexity. Yes, I agree - it isn't like head const is bad o

Re: Head Const

On 2/16/2016 6:20 PM, Dicebot wrote: The problem with this DIP is that it speaks about type system semantics and what matters first is memory model (which is currently very under-defined as soon as you step from a "the GC" world). Physical immutability is demanding but it also has great value

Re: Head Const

On 2/16/2016 11:29 AM, Marc Schütz wrote: For example, it's always possible to use a global mutable associative array to store additional data connected with an immutable or const object (ignoring purity issues for the moment). That's safe because from the outside, there's no observable change

Re: Head Const

On 2/16/2016 5:35 AM, Dicebot wrote: In my opinion @mutable would be a disaster of much higher destructive impact than head const. I am very opposed to it no matter how it is designed. Once you start considering it, you are better at simply throwing away existing const system and starting it all

Re: Head Const

On 02/16/2016 09:29 PM, Marc Schütz wrote: > The last sentence in my post is crucial: "keep most of the existing > guarantees". If we can ensure that access to @mutable data is strongly > restricted and properly encapsulated, we don't lose anything. The type > system would stay as it is, there

Re: Head Const

d to find a way to keep most of >>> the existing guarantees, especially concerning shareability. >> >> >> In my opinion @mutable would be a disaster of much higher destructive >> impact than head const. I am very opposed to it no matter how it is >> designed.

Re: Head Const

shareability. In my opinion @mutable would be a disaster of much higher destructive impact than head const. I am very opposed to it no matter how it is designed. Once you start considering it, you are better at simply throwing away existing const system and starting it all from scratch with D3

Re: Head Const

On Tuesday, 16 February 2016 at 18:06:05 UTC, karabuta wrote: Hahaha. Well, I think it is already happening. Like the reincarnation of C to C++ story. The focus on interfacing D with C++ lately has been very disconcerting, especially considering features from TDPL are still unfinished

Re: Head Const

On Tuesday, 16 February 2016 at 06:04:42 UTC, Jonathan M Davis wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head

Re: Head Const

On Tuesday, 16 February 2016 at 16:27:54 UTC, Jonathan M Davis wrote: considerably. Andrei recently posted about possibly having a reference count be in the memory next to an immutable object but not having it in the object itself, and that might work: I don't think I understand the semantic

  1   2   >