On Wednesday, 2 September 2015 at 04:04:54 UTC, Sergei Degtiarev wrote:
> I seems a little bit too easy to to shoot yourself in the foot.

Yes, cast is a little not fool-proof in this scenario.

On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev wrote:
> Agree, however, memory obtained with mmap(..., PROT_READ, ..); is essentially read-only and any attempt to write to it will cause immediate crash with segmentation violation. It would be very desirable in this case to return something that could be cast to immutable(type)[] but not type[].

If you can't write to it doesn't mean it won't change. Use const for memory that you can't write to.

On Thursday, 3 September 2015 at 16:05:33 UTC, Sergei Degtiarev wrote:
> Absolutely, instead of returning raw void[] and allow user to cast it, std.mmfile should implement template function to return desired type.

Well, interpretation of data can be arbitrarily complex, I'd suggest that the raw data should be passed to your specific parser, that will do the right thing and provide data in expected format.

On Friday, 4 September 2015 at 08:37:26 UTC, Kagamin wrote:
> On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev wrote:
>> Agree, however, memory obtained with mmap(..., PROT_READ, ..); is essentially read-only and any attempt to write to it will cause immediate crash with segmentation violation. It would be very desirable in this case to return something that could be cast to immutable(type)[] but not type[].
>
> If you can't write to it doesn't mean it won't change. Use const for memory that you can't write to.

Note that you can however achieve immutability by using a _private_ read-only mapping.

On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev wrote:
[...]
> Agree, however, memory obtained with mmap(..., PROT_READ, ..); is essentially read-only and any attempt to write to it will cause immediate crash with segmentation violation. It would be very desirable in this case to return something that could be cast to immutable(type)[] but not type[].
> This is what I tried to find out. Thank you for the help.

It can still change by writing (in the same or another process) to the file via another file descriptor. Of course the results are non-deterministic in that case, so it doesn't much matter whether the compiler assumes the data to be immutable or not.

On Friday, 4 September 2015 at 09:05:07 UTC, Marc Schütz wrote:
> Note that you can however achieve immutability by using a _private_ read-only mapping.

man pages say the behavior is unspecified.

On Friday, 4 September 2015 at 13:29:42 UTC, Kagamin wrote:
> On Friday, 4 September 2015 at 09:05:07 UTC, Marc Schütz wrote:
>> Note that you can however achieve immutability by using a _private_ read-only mapping.
>
> man pages say the behavior is unspecified.

The Linux man page says:

"It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region."

I.e., you're right. I interpreted this to refer only to portions of the file that have never been accessed, but reading it again, it doesn't say that... And it makes sense, as this makes it possible to drop clean pages on memory pressure, instead of swapping them out.