May 10, 2007
Chris Nicholson-Sauls wrote:
> Which gets me to thinking: will const parameters be implicitly passed by referance?

No. Use reference parameters to pass by reference.
May 10, 2007
Sean Kelly wrote:
> I'm not sure if anyone has asked yet, but will there be a
> predefined version identifier for 1.0 vs. 2.0?  To migrate
> gradually, it might be useful if there were a way to make code
> cross-compilable.

I haven't got that far yet. Probably.
May 10, 2007
Walter Bright wrote:
> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. 

Life on the bleeding edge. That's why we're here, right?

> I'm trying to minimize any source incompatibilities.

Considering the possibly several versions with problems, I don't see minimizing source incompatibilities as a priority. Rather, I'd see even thinking about them as hampering development. Just do what it takes.

> The first few iterations of const support probably will have lots of problems before it gets usable.

> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.

Actually, since we bump the major number here, this would be an excellent time to review even other things that we've skipped so far because of fear of source incompatibilities.

The next good opportunity for breaking source will be D3.0, which probably is a couple of years away. -- And it damn well should, because only then can we have a thriving garden of stable and mature libraries, and serious apps built on them.

(Why are beaches void of plants? Surely it's not for a lack of moisture, sunlight or nutrients. It's because the sea keeps moving the sand before any seeds sprout.)


The pride, or the yardstick that libraries are measured with, should be how well they utilise the stable fork. Only that gives the stability, robustness, predictability, and long-term credibility that are needed before any real company risks choosing D for their pivot applications.

We also have to admit that library writers and app builders have diametrically opposite views on ease of porting between major language versions: library writers prefer language changes that are easy to fix (as with automatic source transforms). But app builders really don't see that as a priority, because new upgrades of the app are usually written with the original language version. It would be un-economical to redo your large app just because you want to upgrade to D n+1. (Of course, the same companies will use the newest language (stable) version for their new apps.)
May 10, 2007
Aarti_pl wrote:
> Any chances to get these branches in the form of open SVN repository accessible from D main page? It would be really big step forward IMHO...

Hi,

Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them.

Regards,
Bastiaan.
May 10, 2007
Bastiaan Veelo pisze:
> Aarti_pl wrote:
>> Any chances to get these branches in the form of open SVN repository accessible from D main page? It would be really big step forward IMHO...
> 
> Hi,
> 
> Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them.
> 
> Regards,
> Bastiaan.

Your link points to GDC sources, but I wrote about DMD sources. GDC is different compiler, with additional modifications necessary to work with gcc. What's more svn repository of DMD sources should be rather accessible from DMD page not from other places...

Source should be available because it's easier to track changes, check out one specific revision of compiler and prepare patches.

I think also that it makes much better impression about openess of compiler development and rises quality of code. It gives also some sort of security, as open projects with many contributors are more likely to survive in longer term...

Of course I am not expecting that Walter will put there sources for programs which are currently closed...

BR
Marcin Kuszczak
(aarti_pl)
May 10, 2007
Aarti_pl wrote:
> Bastiaan Veelo pisze:
> Your link points to GDC sources, but I wrote about DMD sources. GDC is different compiler, with additional modifications necessary to work with gcc. 

1

> What's more svn repository of DMD sources should be rather accessible from DMD page not from other places...

2

> Source should be available because it's easier to track changes, check out one specific revision of compiler and prepare patches.

3

> I think also that it makes much better impression about openess of compiler development and rises quality of code. It gives also some sort of security, as open projects with many contributors are more likely to survive in longer term...

You make three good points!

> Of course I am not expecting that Walter will put there sources for programs which are currently closed...
May 10, 2007
Walter Bright wrote:
> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
> 
> The first few iterations of const support probably will have lots of problems before it gets usable.
> 
> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.

I imagine, you would want to fork the documentation while your at it.

-Joel
May 10, 2007
Walter Bright a écrit :
> Chris Nicholson-Sauls wrote:
>> Actually, that'll be 'final'.  The new 'invariant' will mean "this *data* absolute does not change", and the new 'const' will mean "this is an *immutable view* into data owned by other code, which *may* change".  (If I'm remembering/understanding right.)
> 
> You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

renoX
May 10, 2007
Nah, 'foreach_reverse' is longer.

On 5/10/07, renoX <renosky@free.fr> wrote:
> Walter Bright a écrit :
> > Chris Nicholson-Sauls wrote:
> >> Actually, that'll be 'final'.  The new 'invariant' will mean "this
> >> *data* absolute does not change", and the new 'const' will mean "this
> >> is an *immutable view* into data owned by other code, which *may*
> >> change".  (If I'm remembering/understanding right.)
> >
> > You're right.
>
> If the keywords are really like this, it's a bit weird, IMHO the most
> interesting one is 'invariant' which happens to be also the one with the
> longest name..
>
> renoX
>


-- 
Anders

May 10, 2007
Aarti_pl wrote:
> Bastiaan Veelo pisze:
>> Aarti_pl wrote:
>>> Any chances to get these branches in the form of open SVN repository accessible from D main page? It would be really big step forward IMHO...
>>
>> Hi,
>>
>> Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them.
>>
>> Regards,
>> Bastiaan.
> 
> Your link points to GDC sources, but I wrote about DMD sources.

I know.

> GDC is different compiler, with additional modifications necessary to work with gcc. What's more svn repository of DMD sources should be rather accessible from DMD page not from other places...

Unless I missed a significant change in Walter's position on what to give away, only the front-end to the dmd compiler is published, besides Phobos. Although these sources are extremely valuable, I wonder what you would do when they were more easily accessible; hence my question.

> Source should be available because it's easier to track changes,

OK,

> check out one specific revision of compiler

No, a front-end alone does not make a compiler. GDC on the other hand is.

> and prepare patches.

Unlikely, patches to a front-end that you cannot test yourself. I'd like to know if I am mistaken! OTOH, patches to GDC you can test. Then I suppose they could be ported to upstream DMD front-end. Still not sure whether a repository would help a lot here.

> I think also that it makes much better impression about openess of compiler development and rises quality of code. It gives also some sort of security, as open projects with many contributors are more likely to survive in longer term...
> 
> Of course I am not expecting that Walter will put there sources for programs which are currently closed...

But the DMD compiler is still partly closed. I doubt that a repository for the front-end has much to say for the number of contributors. Phobos is an other issue however.

I agree that it may be positive for a first impression to have a link to a repository on the DMD website, but it would only be for looking at it.  Personally I like working with Subversion, even for projects where I am the only contributor. But it requires a new way of working if you are not used to it, and I can understand it if Walter does not want to change his procedures for this small benefit.

Every now and then there is a post that is somehow about the lack of DMD as compared to a completely open source project. Be it number of contributors, eternity, quality of code (never heard that one before though) freedom, etc. *But we have GDC that provides all that*. And GDC exists by the grace of Walter, he is giving away the parts that are required for it. Of course we would all love to see DMD completely open source, but it sounds like a bit much to ask! And now we have two compilers instead of just one :-)

Bastiaan.