> On Dec 23, 2016, at 2:02 PM, Xiaodi Wu <[email protected]> wrote:
>
> I don't currently have a use for it, but I can certainly see how this might
> be useful to some people.
>
> As a side note, though, it seems like the consensus is that the optimization
> shown in your specific example, which is provided by std::vector<bool> in
> C++, is now widely regarded as a poor design choice. See, for instance,
> <http://stackoverflow.com/questions/17794569/why-is-vectorbool-not-a-stl-container
>
> <http://stackoverflow.com/questions/17794569/why-is-vectorbool-not-a-stl-container>>,
> <https://isocpp.org/blog/2012/11/on-vectorbool
> <https://isocpp.org/blog/2012/11/on-vectorbool>>, and
> <http://www.gotw.ca/publications/N1211.pdf
> <http://www.gotw.ca/publications/N1211.pdf>>.
>
> It would be interesting to see if you can come up with a use case where the
> proposed feature is a clear win as opposed to just having a totally separate
> type that makes clear it's not quite the same thing under the hood (in your
> example, something like `BitArray`).
I'm starting to think my original motivation might’ve had something to do with
normally needing storage for both some property and a T, but not needing
(local) storage for said property if T conformed to a protocol which itself
already required conforming types to have that property? Or maybe as a way to
have the “bottom” variable in a hierarchy of wrapper types to break the
“reference cycle” for some property? (Come to think of it, those could be the
same thing)
That was (and is) an odd project... Anyway, it's been a while since I've
thought about it. I'll try to find time today to poke through some old code and
see if still have a copy of what I’d gotten stuck on.
And thanks for those links :-)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
