Hi - > Even though r is defined to be constant, it clearly is being changed
It's my personal view that this just indicates some missing parts in our implementation of const-checking. I think it should be an error. I don't know whether or not others agree with me. -michael On 6/11/16, 1:55 AM, "Nikhil Padmanabhan" <[email protected]> wrote: > >Hi Brad, Brian --- > > >Brad -- thanks for that very detailed explanation. I think all of it >makes sense -- although it does make it clear that reasoning about eg. >the locality of an object from the source code is sometime subtle. > > >However, your discussion of const ref/in for record types brings up >another oddity. Consider the following : > > >record R { > var x : int = 3; > proc setX(y : int) { > x = y; > } >} > > >proc main() { > const r : R; > writeln(r); > r.setX(10); > writeln(r); >} > > > >If I run it, I get : >(x = 3) >(x = 10) > > >Even though r is defined to be constant, it clearly is being changed --- >and I believe that's because Chapel methods today don't have any notion >of const-ness. So, eg. marking an record const ref/in going into a forall >loop by default will not prevent > a user from creating a data race. Furthermore, I suspect this might >break the remote forwarding semantics... although I haven't tried to >verify this. > > >Thoughts? >-- Nikhil > > > > > > > > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
