[Issue 7381] Make auto tail-const

https://issues.dlang.org/show_bug.cgi?id=7381 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --

[Issue 22550] tail const C++ class not usable on Windows

https://issues.dlang.org/show_bug.cgi?id=22550 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --

[Issue 22550] tail const C++ class not usable on Windows

-dlang created dlang/dmd pull request #13369 "Fix issue 22550 - tail const C++ class not usable on Windows" fixing this issue: - Fix issue 22550 - tail const C++ class not usable on Windows This changes the C++ mangling of const(Class) from "Class const * const" to "C

[Issue 22550] tail const C++ class not usable on Windows

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

[Issue 22550] tail const C++ class not usable on Windows

https://issues.dlang.org/show_bug.cgi?id=22550 Tim changed: What|Removed |Added Keywords||C++ --

[Issue 22550] New: tail const C++ class not usable on Windows

https://issues.dlang.org/show_bug.cgi?id=22550 Issue ID: 22550 Summary: tail const C++ class not usable on Windows Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal

Re: Implementing tail-const in D

On Monday, 29 January 2018 at 13:07:05 UTC, Simen Kjærås wrote: On Thursday, 25 January 2018 at 21:33:10 UTC, Simen Kjærås wrote: On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote: In fact, if the standard implementation of opHeadMutable is basically the same across all types (or

Re: Implementing tail-const in D

On Thursday, 25 January 2018 at 21:33:10 UTC, Simen Kjærås wrote: On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote: In fact, if the standard implementation of opHeadMutable is basically the same across all types (or most types), it could even be provided as a mixin template in

Re: Implementing tail-const in D

On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote: I like this idea quite much, actually, in spite of the lack of support for implicit conversions, which is a loss (but as you said, we can't support that without breaking a lot of existing stuff or introducing massive changes that

Re: Implementing tail-const in D

On Tue, Jan 23, 2018 at 09:36:03AM +, Simen Kjærås via Digitalmars-d wrote: [...] > struct R(T) { > T[] arr; > auto opHeadMutable(this This)() { > import std.traits : CopyTypeQualifiers; > return R!(CopyTypeQualifiers!(This, T))(arr); > } > } > > This is the code

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 14:55:39 UTC, Simen Kjærås wrote: auto map(alias fn, R)(R r) if (isInputRange!(HeadMutable!R)) { // Pass head-mutable versions to MapResult. return MapResult!(fn, HeadMutable!R)(headMutable(r)); } Another thing that I didn't think of when writing the

Re: Implementing tail-const in D

On Wednesday, 24 January 2018 at 11:21:59 UTC, Nick Treleaven wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Unqual is the standard way today to get a head-mutable version of something. For dynamic arrays, static arrays, pointers and value types, including structs

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Unqual is the standard way today to get a head-mutable version of something. For dynamic arrays, static arrays, pointers and value types, including structs without aliasing, thi works. For AAs, classes, and structs with aliasing,

Re: Implementing tail-const in D

On 2018-01-24 00:10, sarn wrote: Have you seen Rebindable in Phobos?  I know it's not the same thing as what you're talking about, but it's relevant. https://dlang.org/library/std/typecons/rebindable.html I'm pretty sure he has since it's use in the implementation [1] ;) [1]

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Since tail-const (more correctly called head-mutable) was mentioned here lately (in the 'I closed a very old bug!'[1] thread), I've been racking my brain to figure out what needs doing to make a viable solution. Have you seen

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 14:17:26 UTC, Andrea Fontana wrote: On Tuesday, 23 January 2018 at 12:39:12 UTC, Simen Kjærås wrote: On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 12:39:12 UTC, Simen Kjærås wrote: On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required for this? A DIP is required for language changes. So yes. No

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required for this? A DIP is required for language changes. So yes. No language changes are proposed - this is all library code. --

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required for this? A DIP is required for language changes. So yes.

Implementing tail-const in D

Since tail-const (more correctly called head-mutable) was mentioned here lately (in the 'I closed a very old bug!'[1] thread), I've been racking my brain to figure out what needs doing to make a viable solution. Unqual is the standard way today to get a head-mutable version of something

Re: Tail Const (Was: I closed a very old bug!)

On Thursday, 18 January 2018 at 09:15:04 UTC, Simen Kjærås wrote: At any rate, this is a topic for a DIP. So, a few more thoughts on this: Arrays and pointers automatically decay to their Unqual'ed variants when passed to a templated function. AAs do not, which makes sense given their

[Issue 5377] Ranges do not support tail-const

https://issues.dlang.org/show_bug.cgi?id=5377 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com

Tail Const (Was: I closed a very old bug!)

On Wednesday, 17 January 2018 at 10:36:44 UTC, Jonathan M Davis wrote: D is quite useable without tail-const, but without it, ranges and const can't be used together. The solution that most of us have taken is basically to give up on const. Having tail-const would be better, but implementing

[Issue 5377] Ranges do not support tail-const

https://issues.dlang.org/show_bug.cgi?id=5377 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 7381] Make auto tail-const

https://issues.dlang.org/show_bug.cgi?id=7381 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --

Re: tail const ?

http://dlang.org/phobos/std_typecons.html#.Rebindable

Re: tail const ?

I don't know about syntax, but D sure needs first-class support of tail immutability. Take this code for example: --- immutable class C { void foo() { // } } void main() { auto c = new C(); c.foo(); } --- Compile it and get Error:

Re: tail const ?

On Thursday, 30 October 2014 at 10:28:42 UTC, Simon A wrote: I don't know about syntax, but D sure needs first-class support of tail immutability. struct A { }

Re: tail const ?

On Thursday, 30 October 2014 at 10:28:42 UTC, Simon A wrote: I don't know about syntax, but D sure needs first-class support of tail immutability. struct A { float * a; void foo() tailconst { writeln(typeof(a).stringof); //outputs const(float) * } } class B { float * a;

tail const ?

As Stewart Gordon mentioned before (2012) What about adding tailConst to the D programming language? tailConst MyStruct a; All fields of the MyStruct would be tailConst and ... tailConst MyClass b; would make the the pointer mutable but all the fields of b const. ...tailImmutable, ...

[Issue 12248] Static arrays have no tail const

https://d.puremagic.com/issues/show_bug.cgi?id=12248 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc ---

[Issue 12248] Static arrays have no tail const

https://d.puremagic.com/issues/show_bug.cgi?id=12248 --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-25 12:34:34 EET --- Wrapping the array in a struct causes .sort to work, but not std.algorithm.sort. Now I'm not sure what the bug is. -- Configure issuemail:

[Issue 12248] New: Static arrays have no tail const

https://d.puremagic.com/issues/show_bug.cgi?id=12248 Summary: Static arrays have no tail const Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: rejects-valid Severity: normal

[Issue 12248] Static arrays have no tail const

https://d.puremagic.com/issues/show_bug.cgi?id=12248 --- Comment #3 from bearophile_h...@eml.cc 2014-02-25 02:49:48 PST --- (In reply to comment #1) Wrapping the array in a struct causes .sort to work, but not std.algorithm.sort. Now I'm not sure what the bug is. Please show the code that

[Issue 12248] Static arrays have no tail const

https://d.puremagic.com/issues/show_bug.cgi?id=12248 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Why D needs tail const

it comes to generic programming. Among other things, if you try to pass it around, you can end up with a mess like const(Rebindable!(const())). This wouldn't happen with built-in tail const support. I guess that, at the code level, tailConst and tailImmutable would be just type modifiers

Re: Why D needs tail const

I'm pretty sure there's a dmd pull request or patch or something for this already. IIRC Michel Fortin implemented it as Object ref obj; (which is the same as Object obj;) and const(Object) ref obj; as tail const. Don't know where it is now though...

Re: Why D needs tail const

On Wednesday, 28 March 2012 at 14:11:10 UTC, Adam D. Ruppe wrote: I'm pretty sure there's a dmd pull request or patch or something for this already. IIRC Michel Fortin implemented it as Object ref obj; (which is the same as Object obj;) and const(Object) ref obj; as tail const. Don't know

Re: Why D needs tail const

Stewart Gordon: OK, so we have std.typecons.Rebindable. But I've found it a PITA when it comes to generic programming. Among other things, if you try to pass it around, you can end up with a mess like const(Rebindable!(const())). This wouldn't happen with built-in tail const support

Re: Why D needs tail const

Stewart Gordon, el 28 de marzo a las 14:54 me escribiste: What do people think to the whole idea? I think this is not an announcement at all and shouldn't be discussed in this list :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/

Re: Why D needs tail const

I'm not sure how my post ended up in .announce, but anyway On 28/03/2012 15:24, bearophile wrote: snip Is it possible to invent a language construct that allows: const(Rebindable!(const())) To be defined as the same as: Rebindable!(const()) You mean be defined the same as

Re: Why D needs tail const

a completely different type if constancy is applied to it could be abused in all kinds of ways, as well as breaking generic programming. And I can't see any other genuine use case it might have. On this basis, we might as well just implement built-in tail const instead. Stewart.

[Issue 7381] New: Make auto tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=7381 Summary: Make auto tail-const Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD

[Issue 7381] Make auto tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=7381 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1

[Issue 7381] Make auto tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=7381 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-27 15:37:11 PST --- Presumably, it would either use the generic type explicitly or use typeof. And if it really wanted const, then it could just use const explicitly. If the

[Issue 6753] Regression(2.055beta) Reinterpret cast of array to a tail const one doesn't work inside @trusted

http://d.puremagic.com/issues/show_bug.cgi?id=6753 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid

[Issue 6753] Regression(2.055beta) Reinterpret cast of array to a tail const one doesn't work inside @trusted

http://d.puremagic.com/issues/show_bug.cgi?id=6753 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 6753] Regression(2.055beta) Reinterpret cast of array to a tail const one doesn't work inside @trusted

Summary|Reinterpret cast of array |Regression(2.055beta) |to a tail const one doesn't |Reinterpret cast of array |work inside @trusted|to a tail const one doesn't ||work inside @trusted --- Comment

[Issue 6753] New: Reinterpret cast of array to a tail const one doesn't work inside @trusted

http://d.puremagic.com/issues/show_bug.cgi?id=6753 Summary: Reinterpret cast of array to a tail const one doesn't work inside @trusted Product: D Version: D2 Platform: Other OS/Version: All Status: NEW

Re: tail const

work that simply, because SimpleRange in this context is the struct, not the template. This, however, works: mixin tailConst!( .SimpleRange, TailT! ); Not sure how I like this. After more problems, I have also come to the conclusion that what is most commonly needed is not really tail-const

Re: tail const

Simen kjaeraas simen.kja...@gmail.com wrote: After more problems, I have also come to the conclusion that what is most commonly needed is not really tail-const, but head-mutable. Why this took me more than a few minutes to consider, I do not know. Common use-cases would then look like

[Issue 5377] New: Ranges do not support tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=5377 Summary: Ranges do not support tail-const Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component

[Issue 5377] Ranges do not support tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=5377 --- Comment #1 from Simen Kjaeraas simen.kja...@gmail.com 2010-12-26 04:03:10 PST --- Created an attachment (id=856) Templates and functions -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are

[Issue 5377] Ranges do not support tail-const

http://d.puremagic.com/issues/show_bug.cgi?id=5377 --- Comment #2 from Simen Kjaeraas simen.kja...@gmail.com 2010-12-26 04:03:37 PST --- Created an attachment (id=857) Proof-of-concept range -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are

Re: tail const

Simen kjaeraas simen.kja...@gmail.com wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 12/4/10 12:23 PM, Simen kjaeraas wrote: To expound further on this, I have created the attached module. Critique wanted. Looks promising. A few comments. * For TailXxx you need to

Re: tail const

On 5-dic-10, at 00:39, Fawzi Mohamed wrote: [...] Thus both have their function, but in general I think that tail const might be even more important (if I had to choose one const/ immutable type I would choose the tail one). This was thought a bit as provocation, but as nobody reacted

Re: tail const

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 12/4/10 12:23 PM, Simen kjaeraas wrote: To expound further on this, I have created the attached module. Critique wanted. Looks promising. A few comments. * For TailXxx you need to handle built-in simple types (int, float...) to

Re: tail const

Simen kjaeraas simen.kja...@gmail.com wrote: I've also considered a template on the form mixin tailConst!( SimpleRange, SimpleRange!( Tail!T ) ); or mixin tailConst!( SimpleRange, Tail!T ); A closer look at this reveals that it won't work that simply, because SimpleRange in this

Re: tail const

On 2010-12-04 02:48:26 -0500, Dmitry Olshansky dmitry.o...@gmail.com said: On 04.12.2010 6:23, Andrei Alexandrescu wrote: On 12/3/10 7:40 PM, Michel Fortin wrote: I have an idea that would fix those: make a template struct/class instance implicitly convertible to another instance of that same

Re: tail const

On 2010-12-04 07:13:30 -0500, Michel Fortin michel.for...@michelf.com said: On 2010-12-04 02:48:26 -0500, Dmitry Olshansky dmitry.o...@gmail.com said: On 04.12.2010 6:23, Andrei Alexandrescu wrote: On 12/3/10 7:40 PM, Michel Fortin wrote: I have an idea that would fix those: make a template

Re: tail const

On 12/4/10 1:48 AM, Dmitry Olshansky wrote: On 04.12.2010 6:23, Andrei Alexandrescu wrote: On 12/3/10 7:40 PM, Michel Fortin wrote: I have an idea that would fix those: make a template struct/class instance implicitly convertible to another instance of that same template if all members share

Re: tail const

On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: If conversion is allowed only for values (i.e. perform a memberwise copy of one struct to another), it looks like things could work. Almost. The problem is that that surreptitious copy completely bypasses

Re: tail const

On 12/4/10 9:58 AM, Michel Fortin wrote: On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: If conversion is allowed only for values (i.e. perform a memberwise copy of one struct to another), it looks like things could work. Almost. The problem is that that

Re: tail const

Simen kjaeraas simen.kja...@gmail.com wrote: What might be appropriate is a function tailconst( T )( T t ) that returns a tail const version of the passed type. That is, given a T[], const(T[]), const(T)[], immutable(T[]), or immutable(T)[], it returns a const(T)[]. For a MyRange!R, const

Re: tail const

On 12/4/10 12:23 PM, Simen kjaeraas wrote: Simen kjaeraas simen.kja...@gmail.com wrote: What might be appropriate is a function tailconst( T )( T t ) that returns a tail const version of the passed type. That is, given a T[], const(T[]), const(T)[], immutable(T[]), or immutable(T

Re: tail const

On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 12/4/10 9:58 AM, Michel Fortin wrote: On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: If conversion is allowed only for values (i.e. perform a memberwise copy of

Re: tail const

On 05.12.2010 0:19, Michel Fortin wrote: On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: I'm not sure why you imply it won't work for references. That's the whole point of the proposal. It can work for references as long as the memory layout is the same and

Re: tail const

, nullable) than what 'ref' currently stands for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays in generic ranges. I have a container C, which defines a range over its elements R. const(R) is not a usable range

Re: tail const

On 12/4/10 3:19 PM, Michel Fortin wrote: On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 12/4/10 9:58 AM, Michel Fortin wrote: On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: If conversion is allowed only for

Re: tail const

is allowed to be templated. This is kind of why I didn't want to rely on templates to do tail-const -- there is just too much power there. Perhaps we can limit compile-time checking of this new const template parameter. If the compiler detects any static check on the const parameter

Re: tail const

be implicitly convertible to T.const_t (or tailconst_t, as may be more appropriate). What might be appropriate is a function tailconst( T )( T t ) that returns a tail const version of the passed type. That is, given a T[], const(T[]), const(T)[], immutable(T[]), or immutable(T)[], it returns a const(T

Re: tail const

syntax is that we're reusing 'ref' to denote an object reference with different properties (rebindable, nullable) than what 'ref' currently stands for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays

Re: tail const

work is this: const(int)[] data = [1,2,3]; auto a = map!a+a(data); foreach (e;a) { } Now, change data to an SList range. This is what I'm talking about. Arrays already enjoy the benefits of tail-const, I want to extend that to all range types (and in fact all struct types). -Steve

Re: tail const

the same for immutable. And now I need to triplicate all my functions which accept the ranges, or return them. And I can't use inout(R) as a return value for ranges. If you can solve the general problem, and not just the class tail-const, it would be hugely beneficial. My thought was that a modifier

Re: tail const

for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays in generic ranges. I have a container C, which defines a range over its elements R. const(R) is not a usable range, because popFront cannot be const. So now I need to define

Re: tail const

for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays in generic ranges. I have a container C, which defines a range over its elements R. const(R) is not a usable range, because popFront cannot be const. So now I need to define

Re: tail const

is now define a completely separate function for opSlice: ConstRange opSlice() const { ConstRange result; result.node = head; // result.node is tail-const } Now, I could possibly make Range just parameterized on the parameterized type, but I still have to create two separate types (whether

Re: tail const

and a new kind of shared. You should realize that for the compiler to know the constness of member variables inside a function, it'll have to know whether the 'this' pointer is 'const' or 'tail const'. So I think it's the wrong path. Yes, Andrei also pointed out this problem. Part

Re: tail const

On 2010-12-03 21:02:10 -0500, Steven Schveighoffer schvei...@yahoo.com said: On Fri, 03 Dec 2010 20:40:23 -0500, Michel Fortin michel.for...@michelf.com wrote: I have an idea that would fix those: make a template struct/class instance implicitly convertible to another instance of that

Re: tail const

On Fri, 03 Dec 2010 21:19:14 -0500, Michel Fortin michel.for...@michelf.com wrote: On 2010-12-03 21:02:10 -0500, Steven Schveighoffer schvei...@yahoo.com said: On Fri, 03 Dec 2010 20:40:23 -0500, Michel Fortin michel.for...@michelf.com wrote: I have an idea that would fix those: make

Re: tail const

On 2010-12-03 21:25:01 -0500, Steven Schveighoffer schvei...@yahoo.com said: On Fri, 03 Dec 2010 21:19:14 -0500, Michel Fortin michel.for...@michelf.com wrote: On 2010-12-03 21:02:10 -0500, Steven Schveighoffer schvei...@yahoo.com said: On Fri, 03 Dec 2010 20:40:23 -0500, Michel Fortin

Re: tail const

On 12/3/10 7:40 PM, Michel Fortin wrote: I have an idea that would fix those: make a template struct/class instance implicitly convertible to another instance of that same template if all members share the same memory layout and each member is implicitly convertible to the same member of the

Re: tail const

On 12/3/10 7:26 PM, Steven Schveighoffer wrote: BTW, even though I conceed that my ideas are too complex to be worth using, I don't agree we must make-do without tail-const. We just need to find a different way to solve the problem. Let's talk about how we could add some sort of custom implicit

Re: tail const

On 04.12.2010 6:23, Andrei Alexandrescu wrote: On 12/3/10 7:40 PM, Michel Fortin wrote: I have an idea that would fix those: make a template struct/class instance implicitly convertible to another instance of that same template if all members share the same memory layout and each member is

Re: tail const

explicit: C a; // mutable reference to mutable class C ref b; // mutable reference to mutable class And now you can apply tail-const to it: const(C)ref c; // mutable reference to const class const(C ref) d; // const reference to const class const(C) e; // const reference to const class

Re: tail const

On 1-dic-10, at 12:10, spir wrote: On Tue, 30 Nov 2010 23:57:04 +0100 Fawzi Mohamed fa...@gmx.ch wrote: Speaking about D mistakes Steve spoke about missing tail const. I was thinking about this, and I fully agree that it is a hole. I don't know if it was already discussed, but I was thinking

Re: tail const

On 2010-12-02 05:57:18 -0500, Fawzi Mohamed fa...@gmx.ch said: well as your are at it I would argue a bit more on the syntax. [...] I suppose that will probably considered too difficult to implement, but I wanted to propose it again because I find that it is the most clean solution

Re: tail const

it's worth it really. ok, eheh I just realized that also the tail shared protection has exactly the same constraints as the weak const (or tail const), and also for that it seems that the more complex struct case was scrapped, restricting it to pointer array and refs. As for the syntax

Re: tail const

for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays in generic ranges. I have a container C, which defines a range over its elements R. const(R) is not a usable range, because popFront cannot be const. So now

Re: tail const

properties (rebindable, nullable) than what 'ref' currently stands for. But it remains the best syntax I've seen so far. Where it would be beneficial is in mimicking the tail-const properties of arrays in generic ranges. I have a container C, which defines a range over its elements R. const(R

Re: tail const

Michel Fortin michel.for...@michelf.com wrote: I'm not sure I get the problem. Can you show me in code? const a = map!a+a( [1,2,3] ); foreach ( e; a ) { } The foreach fails because popFront is not const. What is needed is for typeof(a) to be Map!(a+a, const(int)[]). IOW, is( const(Map!(a+a,

Re: tail const

On 12/2/10 6:54 PM, Simen kjaeraas wrote: Michel Fortin michel.for...@michelf.com wrote: I'm not sure I get the problem. Can you show me in code? const a = map!a+a( [1,2,3] ); foreach ( e; a ) { } The foreach fails because popFront is not const. What is needed is for typeof(a) to be

Re: tail const

Speaking about D mistakes Steve spoke about missing tail const. I was thinking about this, and I fully agree that it is a hole. I don't know if it was already discussed, but I was thinking that one could introduce *const T t1; and *immutable T t2; Sorry if i am overlooking

Re: tail const

On Tue, 30 Nov 2010 23:57:04 +0100 Fawzi Mohamed fa...@gmx.ch wrote: Speaking about D mistakes Steve spoke about missing tail const. I was thinking about this, and I fully agree that it is a hole. I don't know if it was already discussed, but I was thinking that one could introduce

Re: tail const

On Wednesday 01 December 2010 02:56:58 so wrote: Speaking about D mistakes Steve spoke about missing tail const. I was thinking about this, and I fully agree that it is a hole. I don't know if it was already discussed, but I was thinking that one could introduce *const T t1

Re: tail const

The real issue is not syntax but getting it into the compiler. Apparently, there are difficulties in implementing tail const in the compiler which made Walter give up on it in the past. It should be doable, but Walter is totally sick of the issue and doesn't want to put the time in to do

Re: tail const

Hello community, that is my first post here. My background is more than 10 years of C++ and to be positive I would like to say that there are a lot of things I love in D ( perhaps the object of a new thread :O) ). Speaking about D mistakes Steve spoke about missing tail const. I was thinking

Re: tail const

Reading back my first post I realized that there are a lot of confusions... please ignore it and consider the corrected version here: At least one facet of the problem is a syntax problem. Doing a parallel with C++ and concerning pointers there are 4 possible variants: // C++ 1/ int *p; 2/

Re: tail const

vincent picaud vincent.pic...@laposte.net wrote: To summarize there would be just one keyword to add in D : const_. This attribute would have sense only for Objects (the same logic would also hold for immutable_). To my IMHO the syntax const_ is easy to unerstand, because _ clearly shows

Re: tail const

Fortin: I proposed the following a while ago. First allow the class reference to (optionally) be made explicit: C a; // mutable reference to mutable class C ref b; // mutable reference to mutable class And now you can apply tail-const to it: const(C)ref c

  1   2   >