On Mon, Nov 27, 2017 at 6:41 PM, Xidorn Quan <m...@upsuper.org> wrote:
> On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: > > On Mon, Nov 27, 2017 at 4:07 PM, smaug <sm...@welho.com> wrote: > > > And auto makes code reading harder. It hides important information like > > > lifetime management. > > > It happens easily with auto that one doesn't even start to think > whether > > > nsCOMPtr/RefPtr should be used there. > > > > This statement seems perhaps a touch to universalist; it may be the case > > that it makes it harder for *you* to read, but I find it makes it easier > > for me to read. I also don't think it's a coincidence that it's a common > > feature of modern languages (Rust and Go, to name just two), so I suspect > > I'm not alone in thinking auto is a good thing. > > Using Rust and Go as examples isn't very fair. > > Go has GC, and Rust has compile-time lifetime checking, so they are > basically free from certain kind of lifetime issues. I don't think that it's unfair. My point was that these are features that language designers and users think are desirable, which is why they get added to languages. After all, you could certainly build a language like Rust or Go that didn't have any type inference; people would just wonder what you were thinking. And I strongly suspect they got added to C++ for the same reason. With that said, this kind of lifetime issue in C++ largely arises from the use of raw pointers (or auto_ptr, I guess, though that's been deprecated), and in the specific cases under discussion here, by intermixing old-style memory management with a bunch of the newer features. We could of course deal with that by not letting anybody use the new features, but it seems like a more promising direction would be to move to a more modern memory management idiom, which C++-14 already supports. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
