phobos commit, revision 2032


user: dsimcha

msg:
Bug 4888:  Heavy reliance on Bug 3534 in Phobos range usage.  I used a different approach here than the first one I tried.  I only did what was necessary to make Phobos work instead of trying to fix the deeper issue of making std.algorithm to work w/ const/immutable arrays.

http://www.dsource.org/projects/phobos/changeset/2032

One important advantage we have in working on Phobos is that we have Walter on board, who can help us. I think we should convince Walter of giving priority to byg 3534 and then undo this diff.

Andrei

On 09/18/2010 04:00 PM, dsource.org wrote:
> phobos commit, revision 2032
>
>
> user: dsimcha
>
> msg:
> Bug 4888:  Heavy reliance on Bug 3534 in Phobos range usage.  I used a different approach here than the first one I tried.  I only did what was necessary to make Phobos work instead of trying to fix the deeper issue of making std.algorithm to work w/ const/immutable arrays.
>
> http://www.dsource.org/projects/phobos/changeset/2032
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Which is exactly why I suggested that 2.050 try to focus on fixing bugs involving work arounds.  Obviously, it requires buy-in from Walter (and Don), and a list of bugs that are particularly annoying.

My list is pretty much just one bug:

  http://d.puremagic.com/issues/show_bug.cgi?id=3516
  Destructor not called on temporaries



On 9/19/2010 3:58 PM, Andrei Alexandrescu wrote:
> One important advantage we have in working on Phobos is that we have Walter on board, who can help us. I think we should convince Walter of giving priority to bug 3534 and then undo this diff.
> 
> Andrei
> 
> On 09/18/2010 04:00 PM, dsource.org wrote:
>> phobos commit, revision 2032
>>
>>
>> user: dsimcha
>>
>> msg:
>> Bug 4888:  Heavy reliance on Bug 3534 in Phobos range usage.  I used a
>> different approach here than the first one I tried.  I only did what was
>> necessary to make Phobos work instead of trying to fix the deeper issue of
>> making std.algorithm to work w/ const/immutable arrays.
>>
>> http://www.dsource.org/projects/phobos/changeset/2032
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 20 September 2010 03:31, Brad Roberts <braddr at puremagic.com> wrote:
> Which is exactly why I suggested that 2.050 try to focus on fixing bugs involving work arounds. ?Obviously, it requires buy-in from Walter (and Don), and a list of bugs that are particularly annoying.
>
> My list is pretty much just one bug:
>
> ?http://d.puremagic.com/issues/show_bug.cgi?id=3516 ?Destructor not called on temporaries

That's my bug#1, too. The next two on my list are this:

2451 Adding structs that use opAssign or postblit to an AA is broken
(1886 is a duplicate)
2943 Struct copying in presence of alias member this only copies alias
this member

Then comes about ten regression and wrong-code bugs + five which are in the list of patches I recently posted.

I originally had a list of 50 terrible bugs, but most of them have been fixed in the last four or five releases. So I agree that the focus can begin to shift to Phobos blockers.

  I agree for the part of the diff that was related to working around
3534, but most of the diff was to avoid relying on 3534, and to fix
stuff that would break when 3534 was fixed.  The changes in std.array
work around 3534 by explicitly preventing popFront() and popBack() from
being used on const/immutable arrays.  The rest of the diffs fix issues
caused by relying on popFront()/popBack() working on const/immutable
arrays when they shouldn't.

The reason why I committed this changeset was because I realized that there was wholesale reliance on this bug w.r.t. ranges, so I wanted to break this before even more code came to depend on it.  I was concerned that if we waited and let even more code depend on this bug, it would become nearly impossible to fix because so much code would be relying on it.

On 9/19/2010 6:58 PM, Andrei Alexandrescu wrote:
> One important advantage we have in working on Phobos is that we have Walter on board, who can help us. I think we should convince Walter of giving priority to byg 3534 and then undo this diff.
>
> Andrei
>
> On 09/18/2010 04:00 PM, dsource.org wrote:
>> phobos commit, revision 2032
>>
>>
>> user: dsimcha
>>
>> msg:
>> Bug 4888:  Heavy reliance on Bug 3534 in Phobos range usage.  I used
>> a different approach here than the first one I tried.  I only did
>> what was necessary to make Phobos work instead of trying to fix the
>> deeper issue of making std.algorithm to work w/ const/immutable arrays.
>>
>> http://www.dsource.org/projects/phobos/changeset/2032
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I don't think there was reliance on the bug. It was more like accept-invalid kind of stuff - std.algorithm wasn't supposed to work on const arrays, but it sometimes did.

Andrei

On 09/20/2010 07:19 PM, David Simcha wrote:
> I agree for the part of the diff that was related to working around 3534, but most of the diff was to avoid relying on 3534, and to fix stuff that would break when 3534 was fixed. The changes in std.array work around 3534 by explicitly preventing popFront() and popBack() from being used on const/immutable arrays. The rest of the diffs fix issues caused by relying on popFront()/popBack() working on const/immutable arrays when they shouldn't.
>
> The reason why I committed this changeset was because I realized that there was wholesale reliance on this bug w.r.t. ranges, so I wanted to break this before even more code came to depend on it. I was concerned that if we waited and let even more code depend on this bug, it would become nearly impossible to fix because so much code would be relying on it.
>
> On 9/19/2010 6:58 PM, Andrei Alexandrescu wrote:
>> One important advantage we have in working on Phobos is that we have Walter on board, who can help us. I think we should convince Walter of giving priority to byg 3534 and then undo this diff.
>>
>> Andrei
>>
>> On 09/18/2010 04:00 PM, dsource.org wrote:
>>> phobos commit, revision 2032
>>>
>>>
>>> user: dsimcha
>>>
>>> msg:
>>> Bug 4888: Heavy reliance on Bug 3534 in Phobos range usage. I used a
>>> different approach here than the first one I tried. I only did what
>>> was necessary to make Phobos work instead of trying to fix the deeper
>>> issue of making std.algorithm to work w/ const/immutable arrays.
>>>
>>> http://www.dsource.org/projects/phobos/changeset/2032
>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

  Exactly--and several other parts of Phobos relied on std.algorithm
working on const arrays and thus broke when I prevented popFront() and
popBack() from being used on const arrays.

On 9/20/2010 11:21 PM, Andrei Alexandrescu wrote:
> I don't think there was reliance on the bug. It was more like accept-invalid kind of stuff - std.algorithm wasn't supposed to work on const arrays, but it sometimes did.
>
> Andrei
>
> On 09/20/2010 07:19 PM, David Simcha wrote:
>> I agree for the part of the diff that was related to working around 3534, but most of the diff was to avoid relying on 3534, and to fix stuff that would break when 3534 was fixed. The changes in std.array work around 3534 by explicitly preventing popFront() and popBack() from being used on const/immutable arrays. The rest of the diffs fix issues caused by relying on popFront()/popBack() working on const/immutable arrays when they shouldn't.
>>
>> The reason why I committed this changeset was because I realized that there was wholesale reliance on this bug w.r.t. ranges, so I wanted to break this before even more code came to depend on it. I was concerned that if we waited and let even more code depend on this bug, it would become nearly impossible to fix because so much code would be relying on it.
>>
>> On 9/19/2010 6:58 PM, Andrei Alexandrescu wrote:
>>> One important advantage we have in working on Phobos is that we have Walter on board, who can help us. I think we should convince Walter of giving priority to byg 3534 and then undo this diff.
>>>
>>> Andrei
>>>
>>> On 09/18/2010 04:00 PM, dsource.org wrote:
>>>> phobos commit, revision 2032
>>>>
>>>>
>>>> user: dsimcha
>>>>
>>>> msg:
>>>> Bug 4888: Heavy reliance on Bug 3534 in Phobos range usage. I used a
>>>> different approach here than the first one I tried. I only did what
>>>> was necessary to make Phobos work instead of trying to fix the deeper
>>>> issue of making std.algorithm to work w/ const/immutable arrays.
>>>>
>>>> http://www.dsource.org/projects/phobos/changeset/2032
>>>>
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>