I didn't think it would be an issue, because of the principle you mentioned. But it does require extra consideration beyond simply marking the var as immutable.
Specifically, all string API operations must conform to the copy-on-write semantics. Also, as you might expect, any mutability in strings at all break the system, so they must not be allowed to associate, except through a strict conversion process. On Mon, Mar 9, 2009 at 12:58 PM, Geoffrey Irving <[email protected]> wrote: > On Mon, Mar 9, 2009 at 1:35 PM, Rick R <[email protected]> wrote: > > Sorry for asking this because I know this probably not at the top of the > > feature list at the moment, but I don't have anywhere else to make this > > suggestion before I forget it. > > > > I would really like to to see invariant strings be supported as the basic > > string primitive in BitC. > > Invariant Strings are, in my opinion, the largest success to come out of > D. > > They make string intensive code faster and allow for simpler assurance of > > thread-safety. > > They do require GC/Ref counting to work correctly, also, given special > needs > > for copy on write semantics, it would be much more successful when > supported > > by the language itself. I made an Invariant String lib for C++, it > resulted > > in huge performance gains over std::string, but was unwieldy (what isn't > in > > c++ :) ). > > > > Any thoughts on this? > > Immutability is already one of the core principles of the language, so > you're all set. :) > > http://www.bitc-lang.org/docs/bitc/spec.html#3.7 > > Geoffrey > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
