On Sunday, 10 November 2013 at 19:30:30 UTC, Michael wrote:
> search/replace regexp ?)

I think the way I'd do it is combine that with the compiler. So you compile your code. The compiler generates an error. The fixup script checks the errors against the pattern it has and then does the necessary changes on  the file, then writes it back out (perhaps doing a backup and/or user confirmation, like replacing files on a copy: yes, no, yes to all, with yes to all just following that same pattern - if it is a different class of error message, or if the replace would replace two things when it should only be one, it asks for confirmation again)

This actually shouldn't be too hard to write for quite a few things, and using actual errors would be more reliable than a plain find/replace.

The interactive session can go pretty fast

$ fixup
error foo.d line 30 undefined identifier safe
   @safe void foo() {
replace with
   safe void foo() { # BTW I'd highlight the replacement in color too
y/n/yes to all/no to all? yes to all

boom

On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu wrote:
> On 11/10/13 11:14 AM, Timon Gehr wrote:
>> On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
>>> On 11/9/13 1:27 AM, SomeDude wrote:
>>>> I would add that constant breaking changes make the language unfit for
>>>> industrial usage in the long term.
>>>> Let's remember that D is being pushed in production by Andrei at
>>>> Facebook. If the language breaks everything at each release, there is no
>>>> way Facebook or any other company for that matter is going to bet a dime
>>>> on it.
>>>
>>> Agreed with qualifications. We at Facebook are well aware that bumping
>>> the gcc release will inevitably cause breakages, and are able and
>>> willing to put up with them for the sake of the benefits. This of course
>>> is guided by the breakage/benefits ratio.
>>>
>>> Andrei
>>>
>>
>> What about just shipping a fully automated fix-up tool when trivial but
>> major breaking changes happen?
>
> That's nice because in a good way it puts the onus on the breakers. For it to be useful, the tool would have to be rock solid and work in 100% cases.
>
> Andrei

string mixins?

On 11/10/2013 08:45 PM, John Colvin wrote:
> On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu wrote:
>> On 11/10/13 11:14 AM, Timon Gehr wrote:
>>> On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
>>>> On 11/9/13 1:27 AM, SomeDude wrote:
>>>>> I would add that constant breaking changes make the language unfit for
>>>>> industrial usage in the long term.
>>>>> Let's remember that D is being pushed in production by Andrei at
>>>>> Facebook. If the language breaks everything at each release, there
>>>>> is no
>>>>> way Facebook or any other company for that matter is going to bet a
>>>>> dime
>>>>> on it.
>>>>
>>>> Agreed with qualifications. We at Facebook are well aware that bumping
>>>> the gcc release will inevitably cause breakages, and are able and
>>>> willing to put up with them for the sake of the benefits. This of
>>>> course
>>>> is guided by the breakage/benefits ratio.
>>>>
>>>> Andrei
>>>>
>>>
>>> What about just shipping a fully automated fix-up tool when trivial but
>>> major breaking changes happen?
>>
>> That's nice because in a good way it puts the onus on the breakers.
>> For it to be useful, the tool would have to be rock solid and work in
>> 100% cases.
>>
>> Andrei
>
> string mixins?

Just let CTFE thread through additional state describing the locations of the constant literals the code is assembled from, and make sure the fix-ups do not influence anything else. For the off chance that some part of the generated code that we want to change is actually computed from other data, it is still possible to require manual interaction, but I don't know of any real code for which this might be the case.

Code relying on stringof, eg. stringof returning '@safe' in types instead of 'safe' would be quite hard to handle as well, but it should still be possible to handle the relevant subset of cases.

Of course, such a tool would be quite a piece of engineering. :o)

This is exactly what I suggested at Dconf, and this is what go has done
with go fix:
http://golang.org/cmd/fix/
so it can definitely be done. After using that, user can just use git diff
and see summary of changes if he wants. That is *the* path to improving D's
API. Code with source can be changed, compiled code without source doesn't
need to be changed.
The discussion should focus on how to help with harder cases involving
string mixins found while executing CTFE.
Btw, refactoring code with AST macros should be easier than with string
mixins.


On Sun, Nov 10, 2013 at 11:36 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Sunday, 10 November 2013 at 19:30:30 UTC, Michael wrote:
>
>> search/replace regexp ?)
>>
>
> I think the way I'd do it is combine that with the compiler. So you compile your code. The compiler generates an error. The fixup script checks the errors against the pattern it has and then does the necessary changes on  the file, then writes it back out (perhaps doing a backup and/or user confirmation, like replacing files on a copy: yes, no, yes to all, with yes to all just following that same pattern - if it is a different class of error message, or if the replace would replace two things when it should only be one, it asks for confirmation again)
>
> This actually shouldn't be too hard to write for quite a few things, and using actual errors would be more reliable than a plain find/replace.
>
> The interactive session can go pretty fast
>
> $ fixup
> error foo.d line 30 undefined identifier safe
>    @safe void foo() {
> replace with
>    safe void foo() { # BTW I'd highlight the replacement in color too
> y/n/yes to all/no to all? yes to all
>
> boom
>

On 2013-11-10 20:14, Timon Gehr wrote:

> What about just shipping a fully automated fix-up tool when trivial but
> major breaking changes happen?

Yet again, where's that D front end as a library when we need it.

-- 
/Jacob Carlborg

On Sunday, 10 November 2013 at 20:12:39 UTC, Timon Gehr wrote:
> Code relying on stringof, eg. stringof returning '@safe' in types instead of 'safe' would be quite hard to handle as well, but it should still be possible to handle the relevant subset of cases.

I think it was somewhat decided that .stringof can't be relied upon anyways, when it changed and broke a bit of existing code previously.

> What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?

I'd definitely vote for a fix-up tool. I think it's fair on developers to make a change for consistency of the language whilst providing a mostly automated means to do a one-off fix. It'd be a small onus on a tiny subset of developers to sort out any extraordinary edge cases.

The alternative is to slowly build up a menagerie of quirks that put us on the same path as C++. I'm sure many of us would spend a bit of time writing a clever tool if it means we can rid ourselves of inconsistencies before they breed like rabbits. And it's better to make a change in the near term than to consider it in 5 years time.

On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
> The alternative is to slowly build up a menagerie of quirks that put us on the same path as C++.

It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option.

Ultimately if we try and keep everyone happy, at some point no one will be happy, so I think it's worth trying to find good solutions to enable the language to evolve in ways that can leave baggage from the past behind.

--rt

On 11/10/13 3:39 PM, Rob T wrote:
> On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
>> The alternative is to slowly build up a menagerie of quirks that put
>> us on the same path as C++.
>
> It seems that a buildup of quirks is underway as is evidenced by this
> discussion. The other solution is to at some point place a freeze on D2
> with bug support only and move on to D3 with at least the worse of the
> known baggage removed. There are of course disadvantages and dangers
> with doing that, but it is an option.

No. This is not negotiable.

Andrei

On Monday, November 11, 2013 00:39:04 Rob T wrote:
> On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
> > The alternative is to slowly build up a menagerie of quirks that put us on the same path as C++.
> 
> It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option.
> 
> Ultimately if we try and keep everyone happy, at some point no one will be happy, so I think it's worth trying to find good solutions to enable the language to evolve in ways that can leave baggage from the past behind.

I think that it's naive to think that any serious language will avoid building up quirks and rough corners over time. You never get a language completely right (assuming that's even possible), and you only have so long after you create it to tweak stuff before it has to be more or less set in stone for it to be useable in the real world. Some stuff can be tweaked over time even after you're "stable," but you have to be very careful about it in order to minimize if not outright eliminate breakage. And the longer that a language is around, the more unwieldy it's going to get. Either it doesn't innovate at all and avoids building up more quirks, or it innovates and ends up with quirks as it adds and adjusts stuff after the fact.

Eventually, the baggage from those quirks will be big enough that if you want to get rid of them, you'll be forced to either create a new language or to create a new version of the language which breaks backwards compatiibiity, which tends to be little different from just creating a new language. I really don't think that there's any way around that. D doesn't have all of the baggage of C and C++, because it's a new language which breaks compatibility with them, but it's building up its own quirks and mistakes and will continue to do so. We should do our best to minimize that, but I really don't think that there's any way avoid it completely.

Languages _need_ to be more or less set in stone in order to be useable in the real world, and if you set them in stone, then you're going to end up with quirks and baggage when you add onto them later. That's just the way it is, and I think that anyone who thinks that D can avoid the same fate as C++ in that regard is being naive. Some day, there will be a D++, or a D3, or an E, or whatever for the same reason that we created D instead of continuing to use C++ and for the same reason that the python developers created python 3. But that's a _long_ way off. First, we have to make D2 work, and part of that means living with at least some of the mistakes that we've made and quirks that the language has acquired. And honestly, many of those are tradeoffs that I don't think that anyone has a good solution for at this point anyway. So, even if someone went and created D3 right now, I don't think that it would be appreciably better than D2 (in some regards maybe, but not enough to be worth the split that that would cause to the code and to the community).

- Jonathan M Davis