On Wednesday, October 27, 2010 14:33:17 David Simcha wrote:
> I agree 100% that startsWith needs to work with immutable(X[]). Nonetheless, the proper way to address this is by fixing the language, not by relying on expedient bugs.  I insisted on fixing this because history has shown that if too many people start relying on behavior that is clearly a bug but happens to be expedient, the bug becomes politically unfixable no matter how wrong the behavior is.  Fixing the rest of Phobos such that startsWith() and similar functions will work with immutable(X[]) without relying on Bug 3534 would have been a monumental task (I tried).
> 
> My proposal for dealing with this issue has always been that IFTI should instantiate a function with an Unqual!(T) when passed a T, if and only if the given T is implicitly convertible to Unqual!(T).  For example:
> 
> void foo(T)(T arg) {}
> 
> immutable str = "A family of foxes found food in the forest.";
> foo(str);  // Equivalent to foo!(immutable(char)[])(str);
> 
> immutable num = 2;
> foo(num);  // Equivalent to foo!(int)(num);
> 
> const myRetro = retro([1,2,3,4,5,6]);
> foo(myRetro);  // const(Retro!(int[])) doesn't implicitly convert to
>                // Unqual!(const(Retro!(int[]))).  No Unqual applied.

Well, this change is going to break a lot of code (and the fact that string literals are immutable on Linux but not Windows sure isn't going to help with code portability). We really need to find a permanent solution for this problem soon.

- Jonathan M Davis

On 10/27/2010 7:02 PM, Jonathan M Davis wrote:
> On Wednesday, October 27, 2010 14:33:17 David Simcha wrote:
>> I agree 100% that startsWith needs to work with immutable(X[]). Nonetheless, the proper way to address this is by fixing the language, not by relying on expedient bugs.  I insisted on fixing this because history has shown that if too many people start relying on behavior that is clearly a bug but happens to be expedient, the bug becomes politically unfixable no matter how wrong the behavior is.  Fixing the rest of Phobos such that startsWith() and similar functions will work with immutable(X[]) without relying on Bug 3534 would have been a monumental task (I tried).
>>
>> My proposal for dealing with this issue has always been that IFTI should instantiate a function with an Unqual!(T) when passed a T, if and only if the given T is implicitly convertible to Unqual!(T).  For example:
>>
>> void foo(T)(T arg) {}
>>
>> immutable str = "A family of foxes found food in the forest.";
>> foo(str);  // Equivalent to foo!(immutable(char)[])(str);
>>
>> immutable num = 2;
>> foo(num);  // Equivalent to foo!(int)(num);
>>
>> const myRetro = retro([1,2,3,4,5,6]);
>> foo(myRetro);  // const(Retro!(int[])) doesn't implicitly convert to
>>                 // Unqual!(const(Retro!(int[]))).  No Unqual applied.
> Well, this change is going to break a lot of code

You're right, but it had to be done eventually and holding off and doing it later would only break even more code.

>   (and the fact that string
> literals are immutable on Linux but not Windows sure isn't going to help with
> code portability).

Since when are string literals not immutable on Windows?  They definitely are in D2.

> We really need to find a permanent solution for this problem soon.

Right.  I've been somewhat disappointed that my IFTI proposal has generated so little comment.  IMHO it would solve a whole family of issues related to the interaction between generic code and const/immutable.  These issues are so pervasive that std.math.pow() didn't even work with immutable numeric primitives until a few releases ago when I put in some kludges to make it work.

> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
> 
> Well, this change  is going to break a lot of code (and the fact that string literals are  immutable on Linux but not Windows sure isn't going to help with

> code  portability). We really need to find a permanent solution for this
>problem
>
> soon.

You are misunderstanding the issue.

In an immutable(char)[], the array is mutable, the data it points to is immutable.  The case being discussed is immutable(char[]), where both the data being pointed to *and* the array itself are immutable.  You should not be able to call popFront on such an array.  In no case is the compiler allowing you to change the immutable data being pointed to, that's not what the bug is about.

I agree with everything David has said about it, breaking existing code now is a much better solution than breaking it later, especially when Phobos is in such a volatile state.

-Steve

On Wednesday 27 October 2010 18:16:16 David Simcha wrote:
> On 10/27/2010 7:02 PM, Jonathan M Davis wrote:
> > On Wednesday, October 27, 2010 14:33:17 David Simcha wrote:
> >> I agree 100% that startsWith needs to work with immutable(X[]). Nonetheless, the proper way to address this is by fixing the language, not by relying on expedient bugs.  I insisted on fixing this because history has shown that if too many people start relying on behavior that is clearly a bug but happens to be expedient, the bug becomes politically unfixable no matter how wrong the behavior is.  Fixing the rest of Phobos such that startsWith() and similar functions will work with immutable(X[]) without relying on Bug 3534 would have been a monumental task (I tried).
> >> 
> >> My proposal for dealing with this issue has always been that IFTI should instantiate a function with an Unqual!(T) when passed a T, if and only if the given T is implicitly convertible to Unqual!(T).  For example:
> >> 
> >> void foo(T)(T arg) {}
> >> 
> >> immutable str = "A family of foxes found food in the forest.";
> >> foo(str);  // Equivalent to foo!(immutable(char)[])(str);
> >> 
> >> immutable num = 2;
> >> foo(num);  // Equivalent to foo!(int)(num);
> >> 
> >> const myRetro = retro([1,2,3,4,5,6]);
> >> foo(myRetro);  // const(Retro!(int[])) doesn't implicitly convert to
> >> 
> >>                 // Unqual!(const(Retro!(int[]))).  No Unqual applied.
> > 
> > Well, this change is going to break a lot of code
> 
> You're right, but it had to be done eventually and holding off and doing it later would only break even more code.
> 
> >   (and the fact that string
> > 
> > literals are immutable on Linux but not Windows sure isn't going to help with code portability).
> 
> Since when are string literals not immutable on Windows?  They definitely are in D2.

It says it on the page for dmd: http://www.digitalmars.com/d/2.0/dmd- windows.html :

String literals are read-only under Linux. Attempting to write to them will cause a segment violation.

> > We really need to find a permanent solution for this problem soon.
> 
> Right.  I've been somewhat disappointed that my IFTI proposal has generated so little comment.  IMHO it would solve a whole family of issues related to the interaction between generic code and const/immutable.  These issues are so pervasive that std.math.pow() didn't even work with immutable numeric primitives until a few releases ago when I put in some kludges to make it work.

I suspect that too many people just haven't been worrying about const or immutable much - either because they don't care about them or found them too much of a pain to use in the past and stopped messing with them. We definitely need to sort it out though, and if your proposed solution is a good one, then we really should look into it.

- Jonathan M Davis

On Wednesday 27 October 2010 19:52:42 Steve Schveighoffer wrote:
> ----- Original Message ----
> 
> > From: Jonathan M Davis <jmdavisProg at gmx.com>
> > 
> > Well, this change  is going to break a lot of code (and the fact that string literals are  immutable on Linux but not Windows sure isn't going to help with
> > 
> > code  portability). We really need to find a permanent solution for this
> >
> >problem
> >
> > soon.
> 
> You are misunderstanding the issue.
> 
> In an immutable(char)[], the array is mutable, the data it points to is immutable.  The case being discussed is immutable(char[]), where both the data being pointed to *and* the array itself are immutable.  You should not be able to call popFront on such an array.  In no case is the compiler allowing you to change the immutable data being pointed to, that's not what the bug is about.
> 
> I agree with everything David has said about it, breaking existing code now is a much better solution than breaking it later, especially when Phobos is in such a volatile state.

The problem is string literals. Aren't string literals immutable(char[])? It seems incredibly stupid to have to write

str.startsWith("hello"[])

instead of

str.startsWith("hello")


Now, if some sort of implicit conversion needs to take place here and works because it's a temporary, then that's fine with me. But having to throw around extra [] is going to be really annoying. Sure, in the general case, immutable ranges shouldn't work - that makes sense - but if string literals fall in that category, _that_ is what I have a problem with.

- Jonathan M Davis

On 10/28/2010 1:24 AM, Jonathan M Davis wrote:
> The problem is string literals. Aren't string literals immutable(char[])? It seems incredibly stupid to have to write
No, string literals are immutable(char)[].  The following code compiles w/ the latest beta:

import std.string;

void main() {
     bool result = startsWith("Foo", "Fo");
}

On Thursday, October 28, 2010 06:16:46 David Simcha wrote:
> On 10/28/2010 1:24 AM, Jonathan M Davis wrote:
> > The problem is string literals. Aren't string literals immutable(char[])? It seems incredibly stupid to have to write
> 
> No, string literals are immutable(char)[].  The following code compiles
> w/ the latest beta:
> 
> import std.string;
> 
> void main() {
>      bool result = startsWith("Foo", "Fo");
> }

I understood that the complaint was that using literals with startsWith() didn't work. It was also my understanding that string literals were immutable(char []). I guess that I misunderstood. Well, then that's fine. Having a range variable that you explicitly made immutable not work with algorithms makes sense. It's just that having string literals fall in that camp would be a big problem and that was my concern.

- Jonathan M Davis