<div dir="ltr">There is no existing code that uses delayed execution so we don't need to worry about breaking it. I think it would be much easier to reason about if forcing an expression was always explicit. I am not sure what you mean with the second case; why are you delaying a function if you care about the observable side-effect?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 4:14 PM, Ed Kellett <span dir="ltr"><<a href="mailto:edk141@gmail.com" target="_blank">edk141@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Fri, 17 Feb 2017 at 19:38 Joseph Jevnik <<a href="mailto:joejev@gmail.com" target="_blank">joejev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_6460670478807473163gmail_msg"><div class="m_6460670478807473163gmail_msg">Delayed execution and respecting mutable semantics seems like a nightmare. For most indexers we assume hashability which implies immutability, why can't we also do that here? Also, why do we need to evaluate callables eagerly?</div></div></blockquote><div><br></div></span><div>Respecting mutability: we just have to always, we don't know if a delayed thing is hashable until we evaluate it. This thing has implications for existing code (since delayed objects can get anywhere) so it should be careful not to do anything too unpredictable, and I think d[k] meaning "whatever is in d[k] in five minutes' time" is unpredictable. One can always delay: d[k] if it's wanted.</div><div><br></div><div>Evaluate calls: because if you don't, there's no way to say "strictly evaluate x() for its side effects".</div></div></div>
</blockquote></div><br></div>