package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
tions are vir­tual," which would mean that package is supposed to be virtual.
But from what I recall, the plan is to leave package as non-virtual. So, is
that indeed the case and the spec needs to be fixed, or is package going to be
made virtual at some point?
- Jonathan M Davis

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
tions are vir­tual," which would mean that package is supposed to be virtual.
But from what I recall, the plan is to leave package as non-virtual. So, is
that indeed the case and the spec needs to be fixed, or is package going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.
--
/Jacob Carlborg

or is package going to be made virtual at some point?
=20
- Jonathan M Davis

=20
Is anyone even using "package"? I've basically never used it.

Well, it's the sort of thing that's more useful with larger programs, s=
o I=20
question how much it's being used, but it definitely can be useful.=20
std.datetime will likely be using it in the near future, since I'm work=
ing on=20
breaking it up into a package (leaving std.datetime to then import ever=
ything=20
in the package).
But regardless, it's currently broken:
http://d.puremagic.com/issues/show_bug.cgi?id=3D143
- Jonathan M Davis

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate
non-tem­plate mem­ber
func­ tions are vir­tual," which would mean that package
is supposed to
be virtual. But from what I recall, the plan is to leave
package as
non-virtual. So, is that indeed the case and the spec needs
to be fixed,
or is package going to be made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

Well, it's the sort of thing that's more useful with larger
programs, so I
question how much it's being used, but it definitely can be
useful.
std.datetime will likely be using it in the near future, since
I'm working on
breaking it up into a package (leaving std.datetime to then
import everything
in the package).
But regardless, it's currently broken:
http://d.puremagic.com/issues/show_bug.cgi?id=143
- Jonathan M Davis

I agree, virtual package function would be nice. ATM, as a
workaround we use a package function which forwards the call to a
protected function, and give the constructors package protection
so only classes in the same package can inherit from it. That
works, but it's not perfect.

be virtual. But from what I recall, the plan is to leave > package as
non-virtual. So, is that indeed the case and the spec needs > to be

fixed,

or is package going to be made virtual at some point?

- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

Well, it's the sort of thing that's more useful with larger programs,
so I
question how much it's being used, but it definitely can be useful.
std.datetime will likely be using it in the near future, since I'm
working on
breaking it up into a package (leaving std.datetime to then import
everything
in the package).
But regardless, it's currently broken:
http://d.puremagic.com/issues/show_bug.cgi?id=143
- Jonathan M Davis

I agree, virtual package function would be nice. ATM, as a workaround we
use a package function which forwards the call to a protected function,
and give the constructors package protection so only classes in the same
package can inherit from it. That works, but it's not perfect.

I'd go further and say that's completely ridiculous. The language should
not impose such stupid semantics on you because of a visibility modifier.
--
- Alex

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate
non-tem­plate mem­ber func­
tions are vir­tual," which would mean that package is
supposed to be virtual.
But from what I recall, the plan is to leave package as
non-virtual. So, is
that indeed the case and the spec needs to be fixed, or is
package going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

In a module based approach, it's not as useful. But for people
who are more used to Java and C# and end up using mostly one
file/module per class, it is indeed useful. I've never had nor
saw a use for overriding a package member though. If there is, C#
partially solves this by 'protected internal' where internal is
essentially package; this allows it to be called as a package
function but still be overridable and accessible from the
inheriting class. I have found a few use cases for it, with a
workaround of making a package function to call the protected
function.

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

I use it. Primarily for utility declarations shared among modules, but
not intended for the outside world. For example, DerelictGL's extension
loader. Incidentally, before reading this I just finished refactoring
another project to use some package-protected stuff. But I've never had
a need (yet) to override anything with package protection outside of the
same module.

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

I use it. Primarily for utility declarations shared among modules, but
not intended for the outside world. For example, DerelictGL's extension
loader. Incidentally, before reading this I just finished refactoring
another project to use some package-protected stuff. But I've never had
a need (yet) to override anything with package protection outside of the
same module.

I see, I see. I guess it's more used in Java because it's the default.
--
/Jacob Carlborg

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

I use it. Primarily for utility declarations shared among modules, but
not intended for the outside world. For example, DerelictGL's extension
loader. Incidentally, before reading this I just finished refactoring
another project to use some package-protected stuff. But I've never had
a need (yet) to override anything with package protection outside of the
same module.

I see, I see. I guess it's more used in Java because it's the default.

Well, it's kind of forced on you in Java when you want classes to interact
without having the functions or variables involved be public, since all public
classes must be in their own file. A lot of those cases can be covered in D by
putting the classes in the same module. So, the value of package is definitely
reduced in D, but it's not gone.
- Jonathan M Davis

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

I use it. It's useful when you wish to create higher-level wrappers
around stuff. (Interestingly, I only ever use package for constructors.)
--
- Alex

package functions are currenly non-virtual.
The spec claims that "all non-static non-private non-template
member func=C2=AD
tions are virtual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.=

So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

Is anyone even using "package"? I've basically never used it.

I use it. It's useful when you wish to create higher-level wrappers =

around stuff. (Interestingly, I only ever use package for constructors=

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
tions are vir­tual," which would mean that package is supposed to be virtual.
But from what I recall, the plan is to leave package as non-virtual. So, is
that indeed the case and the spec needs to be fixed, or is package going to be
made virtual at some point?
- Jonathan M Davis

I think virtuality and package should have nothing to with one another.
package is supposed ot express visibility, not change behavior.

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

I think virtuality and package should have nothing to with one another.
package is supposed ot express visibility, not change behavior.

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

I think virtuality and package should have nothing to with one another.
package is supposed ot express visibility, not change behavior.

100% agree.

Same here, though importantly the compiler can use the information to
optimize away virtuals that cannot be overridden.
Andrei

package functions are currenly non-virtual.
The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
mem­ber func­
tions are vir­tual," which would mean that package is supposed to be
virtual.
But from what I recall, the plan is to leave package as non-virtual.
So, is
that indeed the case and the spec needs to be fixed, or is package
going to be
made virtual at some point?
- Jonathan M Davis

I think virtuality and package should have nothing to with one another.
package is supposed ot express visibility, not change behavior.

Currently we don't have a "virtual" keyword, meaning everything would
need to be virtual.
--
/Jacob Carlborg