On Tuesday, 21 May 2019 at 16:39:29 UTC, H. S. Teoh wrote:
> On Tue, May 21, 2019 at 12:29:55PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
>> [...]
>
> This is a very interesting idea indeed.  Goes along well with Andrei's recent idea of addition vs. replacement.
>
> And I think it's probably not hard to adopt in D (should we deem it a good idea -- that's still arguable): all you need is for module declarations to come with an attached version number, then include that in the mangling. This automatically gives a unique identifier to symbols in the module, so you could import multiple versions of the same module and have the symbols resolve correctly. Just a minor change in module declarations and in module name mangling.
>
> Of course, how to handle imports that may have multiple satisfying versions is another, stickier, question.
>
>
> T

Also, type versioning. Types from different versions would have to be completely separate, which would break function signatures, overloads, introspection etc.

On Wed, May 22, 2019 at 10:55:09AM +0000, John Colvin via Digitalmars-d wrote:
> On Tuesday, 21 May 2019 at 16:39:29 UTC, H. S. Teoh wrote:
> > On Tue, May 21, 2019 at 12:29:55PM -0400, Nick Sabalausky (Abscissa) via
> > Digitalmars-d wrote:
> > > [...]
> > 
> > This is a very interesting idea indeed.  Goes along well with Andrei's recent idea of addition vs. replacement.
> > 
> > And I think it's probably not hard to adopt in D (should we deem it a good idea -- that's still arguable): all you need is for module declarations to come with an attached version number, then include that in the mangling. This automatically gives a unique identifier to symbols in the module, so you could import multiple versions of the same module and have the symbols resolve correctly. Just a minor change in module declarations and in module name mangling.
> > 
> > Of course, how to handle imports that may have multiple satisfying versions is another, stickier, question.
[...]
> Also, type versioning. Types from different versions would have to be completely separate, which would break function signatures, overloads, introspection etc.

It doesn't break, because symbols in D are qualified by module name. So if the module name contains version information, types from different versions will be differently-named. For example, moduleA.ver1_0.myStruct will be distinct from moduleA.ver2_0.myStruct, so you couldn't mix the two together unintentionally without a compile error.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice