D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 7381 - Make auto tail-const
Summary: Make auto tail-const
Status: NEW
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P4 enhancement
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-27 14:40 UTC by Jonathan M Davis
Modified: 2024-12-13 17:58 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Jonathan M Davis 2012-01-27 14:40:46 UTC
IFTI was recently changed with arrays to be tail-const. It would be useful if we could do the same with auto. To quote dsimcha from the newsgroup ( http://www.digitalmars.com/d/archives/digitalmars/D/auto_Top-level_Const_Immutable_152877.html ):

The changes made to IFTI in DMD 2.057 are great, but they reveal another 
hassle with getting generic code to play nice with const.

import std.range, std.array;

ElementType!R sum(R)(R range) {
     if(range.empty) return 0;
     auto ans = range.front;
     range.popFront();

     foreach(elem; range) ans += elem;
     return ans;
}

void main() {
     const double[] nums = [1, 2, 3];
     sum(nums);
}

test.d(8): Error: variable test9.sum!(const(double)[]).sum.ans cannot 
modify const
test.d(14): Error: template instance test9.sum!(const(double)[]) error 
instantiating

Of course this is fixable with an Unqual, but it requires the programmer 
to remember this every time and breaks for structs with indirection. 
Should we make `auto` also strip top-level const from primitives and 
arrays and, if const(Object)ref gets in, from objects?
Comment 1 timon.gehr 2012-01-27 15:27:42 UTC
It would make sense in a way, but how would generic code that preserves the const-ness of some value be written nicely with this in place?
Comment 2 Jonathan M Davis 2012-01-27 15:37:11 UTC
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 dropping of constness would make the assignment not possible though, I would argue that the constness should be kept. So, then as long as the code isn't in a situation where it doesn't need to keep constness but it _wants_ to, auto works great. Whereas now, it's really easy to get into a situation where you end up with a const or immutable variable when you really didn't want one, just because the template was instatiated with a const or immutable type.

In general though, I think that if you want const or immutable, you use const or immutable rather than auto. So, the fact that auto preserves full constness causes far more problems than it would if it just preserved tail-constness.
Comment 3 dlangBugzillaToGithub 2024-12-13 17:58:06 UTC
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18406

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB