Segment violation (was Re: Why I could not cast string to int?)
Timon Gehr
timon.gehr at gmx.ch
Sat Feb 4 14:44:28 PST 2012
On 02/04/2012 11:23 PM, Artur Skawina wrote:
> On 02/04/12 22:20, Timon Gehr wrote:
>> On 02/04/2012 06:55 PM, Artur Skawina wrote:
>>> On 02/04/12 02:03, Timon Gehr wrote:
>>>> On 02/03/2012 11:08 AM, Artur Skawina wrote:
>>>>> On 02/03/12 00:20, Jonathan M Davis wrote:
>>>>>> in is pointless on value types. All it does is make the function parameter
>>>>>> const, which really doesn't do much for you, and in some instances, is really
>>>>>> annoying. Personally, I see no point in using in unless the parameter is a
>>>>>> reference type, and even then, it's often a bad idea with reference types,
>>>>>> because in is really const scope, and the scope is problematic if you want to
>>>>>> return anything from that variable. It's particularly problematic with arrays,
>>>>>> since it's frequently desirable to return slices of them, and scope (and
>>>>>> therefore in) would prevent that. It's useful in some instances (particularly
>>>>>> with delegates), but I'd use in _very_ sparingly. It's almost always more
>>>>>> trouble than it's worth IMHO.
>>>>>
>>>>> BTW, scope should have been the default for *all* reference type function
>>>>> arguments, with an explicit modifier, say "esc", required to let the thing
>>>>> escape. It's an all-or-nothing thing, just like immutable strings - not using
>>>>> it everywhere is painful, but once you switch everything over you get the
>>>>> benefits.
>>>>
>>>> I totally agree. Most function arguments are not escaped. However, it is nice that the shortest storage class, 'in', implies scope.
>>>
>>> There are currently two problems with using "in": a) the one mentioned, where
>>> using in/scope means you can't (or shouldn't be able to) pass the thing to another
>>> function w/o scope marked args, and b) "in" implies "const", which is a problem
>>> because you may want to reassign the argument - a perfectly safe thing to do.
>>> With "const" itself you can use parentheses to limit its scope to not include
>>> the reference itself; the problematic case is the builtin "string" alias, ie
>>> "int f(in string s);" would have to allow reassigning 's' inside the function.
>>>
>>>
>>> Semi-related quiz:
>>>
>>> immutable(char)[] a = "a";
>>> const (char)[] b = "b";
>>>
>>> auto aa = a ~ a;
>>> auto bb = b ~ b;
>>> auto ab = a ~ b;
>>>
>>> writeln("aa: ", typeid(aa), " bb: ", typeid(bb), " ab: ", typeid(ab));
>>>
>>> And the question is: How many people, who have not already been bitten by this,
>>> will give the correct answer to: "What will this program print?"?
>>>
>>
>> I think this is covered in this issue:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=7311
>>
>> But feel free to open a more specific enhancement/bug report.
>
> Apparently, there's already a bug open for everything.
> I'm not sure if it's a good or bad thing. :)
>
> I don't think there's one correct answer here - you're right that unique const
> does not really make sense. But is mutable (non-const) really better than
> immutable? It depends, sometimes you will want one, sometimes the other.
> I first ran into this while doing a custom string class - there it was the cause
> of the one and only cast - (string ~ const(char)[]) can obviously still be a
> string, but the compiler won't accept it without a cast.
> I'm not sure how often you'll want the result of concatenation to be mutable,
> compared to immutable. Anyway, the result really is "unique", not mutable, const
> or immutable, at least until it is converted to one of those, hence the solution
> described below.
>
Well, string = string ~ const(char)[] and char[] = string ~
const(char)[] should work, regardless of the type of immutable[] ~
const[]. The compiler can track the uniqueness of the data at the
expression level without actually introducing a type modifier. There is
precedent: Array literals are covariant, because it is safe. Do you want
to open the enhancement or should I do it? (I really thought I already
had an issue open for this...)
>>> There should have been another class, in addition to immutable/const, say "uniq".
>>> For cases where an expression results in new unique objects. This class implicitly
>>> converts to any of const/immutable and mutates to the new type. IOW
>>>
>>> string a = "a";
>>> char[] b = "b";
>>>
>>> auto c = a ~ b; // typeid(c) == (uniq(char)[])
>>>
>>> string d = c; // Fine, "c" is unique and can be safely treated as a string.
>>> // But, from now on, "c" is (immutable(char)[]) so:
>>> char[] e = c; // Fails.
>>>
>>> // And the other way:
>>>
>>> auto f = a ~ b;
>>> char[] g = f; // OK
>>> string h = f // Fails, as f is now a (char[])
>>>
>>> No need for unsafe-looking casts, just so that the compiler accepts perfectly safe
>>> code, like: "string c = ab;", which would currently fail if used in the above quiz,
>>> and has to be written as "string c = cast(string)ab;". [1]
>>>
>>> artur
>>>
>>> [1] Using a helper template is not different from adding a comment, it only serves
>>> to document /why/ the programmer had to something, which is only a workaround for
>>> a language/compiler limitation. "Compiler" because at least the simple cases could
>>> be silently fixed in a backward compatible way (by not disallowing safe conversions).
>>> "Language" because "uniq" would also be useful when the programmer knows it applies,
>>> but the compiler can't figure it out by itself.
>>
>> I am certain we'll get something like this eventually, once the compiler bug count has shrunk sufficiently. It is a natural thing to add.
>>
>
> It would be great if as many of the /language/ issues were fixed and documented
> as soon as possible. They don't even have to be implemented. What i'm afraid of
> is what will happen once dmd no longer is the normative compiler... Walter did a
> very good job with D, i wouldn't expect others to get even a small part of it
> right; it would be best if by the time the committee hordes start to "fix" things
> there was not much left to fix.
>
> [Changes such as defaulting to scoped args are obviously D3 material, i'm only
> mentioning them so that they're already out there to consider/discuss. But some
> things *can* still be fixed in D2 in a mostly backward compatible way]
>
> artur
More information about the Digitalmars-d-learn
mailing list