Struct augmentation

[TahirAhmadov]

As discussed in #524, we allow "augmenting" structs, for the purposes of code reusability.

1. This is not inheritance like classes.
2. We allow "upcasting" using an implicit operator as a convenience, but that loses the added state of the child struct; there is no "downcasting" (from base to child).
3. C# can use the emitted attribute to make it look like "base" members are also available on the "child"; other languages just see the "base" struct as a field, which they can access, as usual.
4. I purposefully use the word "augment", and not "inherit" (to avoid confusion with class-style inheritance, which is impossible with structs), and not "extend" (to avoid confusion with extensions, both existing extension methods and [Proposal]: Extensions #5497 extensions).
5. Multiple "base" structs can be augmented.

struct Point2D : IEquatable<Point2D>
{
  public Point2D(double x, double y) { this.X = x; this.Y = y; }
  public double X, Y;
  public bool Equals(Point2D obj) { ... }
  public Point2D Add(Point2D obj) => new Point2D(this.X + obj.X, this.Y + obj.Y);
}
struct Point3D augments Point2D : IEquatable<Point3D>
{
  public Point3D(double x, double y, double z) : base(x, y) { this.Z = z; }
  public double Z;
  public int Point2D; // compile error - this field name is reserved
  public bool Equals(Point3D obj) { ... }
}
// which is compiled to
[AugmentedFrom("Point2D")] // the string has the field name
struct Point3D : IEquatable<Point2D>, IEquatable<Point3D> // interfaces are "lifted"
{
  public Point3D(double x, double y, double z) { this.Point2D = new Point2D(x, y); this.Z = z; }
  public Point2D Point2D;
  public double Z;
  public bool Equals(Point2D obj) => this.Point2D.Equals(obj); // have to define interface implementing methods, for boxing purposes
  public bool Equals(Point3D obj) { ... }
  public static implicit operator Point2D(Point3D obj) => obj.Point2D;
}
var p3 = new Point3D(1, 2, 3);
Point2D p2 = p3; // p2.X == 1, p2.Y == 2
p3 = (Point3D)p2; // compile error - no conversion exists (unless defined manually)
double x = p3.X; // becomes p3.Point2D.X
bool b = p3.Equals(p2); // becomes p3.Point2D.Equals(p2)  for performance - 
// no need to call p3.Equals(p2), which was created solely for the interface and boxing
p2 = p3.Add(p2); // becomes p3.Point2D.Add(p2)
object p3Boxed = p3;
var p2Equatable = (IEquatable<Point2D>)p3Boxed; // works - because we "lifted" the interfaces
var p2Unboxed = (Point2D)p3Boxed; // this can be made to work, but would require special logic similarly to Nullable<T>
p2Unboxed = object.UnboxPromoted<Point2D>(p3Boxed); // a new static helper method would be the easy solution here

// ref on "base" struct
void Foo(ref Point2D p) { ... }
Foo(ref p3); // becomes Foo(ref p3.Point2D)

// red on "base" struct's field
void Bar(ref double x) { ... }
Bar(ref p3.X); // becomes Bar(ref p3.Point2D.X)

// multiple structs
struct Point { ... }
struct Size { ... }
struct Rectangle augments Point, Size {
  public Rectangle(int x, int y, int width, int height) : Point(x, y), Size(width, height) { }
}

// extensions/roles
extension Point2DExt : Point2D { void Foo() { ... } }
p3.Foo(); // becomes p3.Point2D.Foo() - or however that's implemented, per roles/extensions feature
public static class Point2DExtOld { public static void Bar(this Point2D This) { ... } }
p3.Bar(); // becomes Point2DExtOld.Bar(p3.Point2D)

abstract struct WrapperBase<T>
{
  public WrapperBase(T value) { this._value = value; }
  T _value;
  public T Value => this._value;
}
struct Weight augments WrapperBase<double>
{
  // no ctor needed - base ctor is propagated automatically
  public Density GetDensity(Volume volume) => new Density(this._value / volume.Value); // custom methods
}
struct Length augments WrapperBase<double>
{
  public Length(double value, LengthUnit lengthUnit) : base(value) { this.LengthUnit = lengthUnit; }
  public LengthUnit LengthUnit { get; } // added domain-specific state
}
var w = new Weight(1.2);
var l = new Length(2.3, LengthUnit.Meter);

// another useful scenario - currently I create all these as classes, for inheritance, but these are unnecessary allocations
struct CreateOrderRequest
{
  string product;
}
struct CreateRecurringOrderRequest augments CreateOrderRequest
{
  int numDaysToRepeat;
}
void CreateOrder(CreateOrderRequest request) { ... }
void CreateRecurringOrder(CreateRecurringOrderRequest  request) { ... }

Open questions:

1. If we add multi-struct augmentation, do we retain implicit operators to each of the "base" structs? It can be weird to convert a Rectangle to Point in the above example. Should it be an explicit operator maybe, or no operator at all?
2. Do we allow the creation of abstract structs? If so, what are the rules? The only possible limitation can be inability to call the constructors, but default can always be assigned to a local variable, for example. Or a blanket ban on using anywhere, except for "augmentation"?
3. Is it worthwhile to introduce a new keyword, augments, or just good old : will do? The upside of augments is that it's clear that this is not class-style inheritance; the downside is it's verbose, and it breaks from C# style - becomes more Java-like, which isn't necessarily a bad thing, but it's a change nonetheless.

If anybody has questions, I will try to answer and update this post, as needed.

[Thaina]

Can this be pass by ref ?

Suppose there is

void DoSomething(ref Point2D point)
{
    point.X = SomeValX;
    point.Y = SomeValY;
}

Point3D p;
DoSomething(ref p);

Possible?

[TahirAhmadov]

No, according to current C# syntax. Also, we can't even make it work if we wanted to: the implicit operator returns a value, and we cannot pass in a ref to a return value.
On second thought, maybe we can add logic to the compiler to sidestep the implicit operator, and just do a ref to the Point2D field directly? @CyrusNajmabadi , help :)

[Thaina]

@TahirAhmadov One possibility is to transpile Augmented when it pass by ref

Point3D p;
DoSomething(ref p);

//// become

DoSomething(ref p.Point2D); // taking the field that it augmented from

//// at compile time

[TahirAhmadov]

I updated the OP to cover this, nobody said this cannot be done, so for now we assume it can be. :)

[HaloFour]

Feels like something that would be very easily implemented with a source generator:

struct Point2D : IEquatable<Point2D>
{
  public Point2D(double x, double y) { this.X = x; this.Y = y; }
  public double X, Y;
  public bool Equals(Point2D obj) { ... }
  public Point2D Add(Point2D obj) => new Point2D(this.X + obj.X, this.Y + obj.Y);
}

[Augments<Point2D>]
partial struct Point3D : IEquatable<Point3D>
{
  public Point3D(double x, double y, double z) {
    this.Point2D = new(x, y);
    this.Z = z;
  }
  public double Z;
  public bool Equals(Point3D obj) { ... }
}

// source generator emits
partial struct Point3D : IEquatable<Point2D>
{
  public Point2D Point2D;
  public bool Equals(Point2D obj) => this.Point2D.Equals(obj); // have to define interface implementing methods, for boxing purposes
  public static implicit operator Point2D(Point3D obj) => obj.Point2D;
}

[TahirAhmadov]

Another downside - see @Thaina 's question above - if we can make ref work through trans-piling, 3) source generator cannot give you that.

[TahirAhmadov]

Even after your update to set Point2D field explicitly, will this compile? The field isn't declared in the code itself - can you reference members which will become available after source generators are run?

[RikkiGibson]

Yes. SGs expect to run in presence of errors such as a member "which will be generated" not being present.

[TahirAhmadov]

So I guess the downside here is lack of editor features? Auto-complete, etc.

[RikkiGibson]

The editor is using the "after SGs are run" view of the compilation. The downside of this is that the performance of the editor can be negatively impacted by misbehaving/poorly optimized source generators.

[CyrusNajmabadi]

I'm curious if we can go a much simpler route. Specifically, have the language just automatically lift members of nested-structs upwards as long as they do not collide with real members in the name-spaces they are lifted to. So, in other words, instead of the above, you just write:

struct Point2D : IEquatable<Point2D>
{
  public Point2D(double x, double y) { this.X = x; this.Y = y; }
  public double X, Y;
  public bool Equals(Point2D obj) { ... }
  public Point2D Add(Point2D obj) => new Point2D(this.X + obj.X, this.Y + obj.Y);
}
struct Point3D : IEquatable<Point3D>
{
   public Point2D Point2d;

  public Point3D(double x, double y, double z) { Point2d = new(x, y); this.Z = z; }
  public double Z;
  public bool Equals(Point3D obj) { ... }
}

And Point3d automatically exposes X, Y, Add etc. from the nested struct.

Put another way, name lookup on Point3d would work by looking up in Point3d first, then inside the nested structs within.

If doing this automatically was undesirable, it could be done through a keyword like promote. So:

struct Point3D : IEquatable<Point3D>
{
   promote public Point2D Point2d;

[TahirAhmadov]

Also, with "augment", the compiler can apply extensions and roles more "naturally". With "promoted fields", it can be done, but looks awkward.

struct Point2D { }
struct Point3D augments Point2D { }
extension Point2DExt : Point2D
{
  void Foo() { ... }
}
var p3 = new Point3D();
p3.Foo(); // becomes p3.Point2D.Foo()

[RikkiGibson]

It seems like there's no need to restrict the containing type to being a struct either, i.e. perhaps it would be reasonable to let such "promoted"/"flattened" fields be declared within class types as well.

[TahirAhmadov]

@RikkiGibson that sounds like a completely different feature to what I envisioned. If we allow "promoting" fields for classes, then we can't really do any of the struct-specific improvements which are valuable. To me, just "flattening" the fields is nowhere near worth doing anything at all.

[RikkiGibson]

If we allow "promoting" fields for classes, then we can't really do any of the struct-specific improvements which are valuable.

It wasn't clear to me why this is the case, could you elaborate?

[TahirAhmadov]

If you look at my proposal, it includes things like interface lifting, one-way "upcast" using an implicit operator, passing "base" struct as ref (thanks to Thaina), etc. None of these things really make sense with classes. For interfaces, it can be done, but it goes against the existing inheritance hierarchy. For "upcasting", it's normal to expect a class to be "castable" to either it's base or child classes (if instance is there), and implemented interfaces; now we're introducing a whole new way of "casting" which is different from how classes work. Same goes for ref - if you have an instance of a class, which has a class-type field, it would be completely unexpected that that field is passed in by ref instead of the class itself.
These reasons are also why I'm unsure about the propriety of using "promoted fields" even for structs; I think of it as "struct augmentation", because it's similar (but not the same) as inheritance, for the struct world. Also for things like extensions, etc. - these don't make sense with promoted fields.

[CyrusNajmabadi]

I think it would be helpful to not only say what would be possible here but also the use cases why it would be valuable. For example the interface/ref stuff just doesn't seem that major. How often do you need to do this, and in those cases, would it be that bad to just say OuterType.InnerProp instead of just passing OuterType naked?

[TahirAhmadov]

You can't do that with interfaces. It doesn't work when boxed without auto-lifting the interfaces.
For ref, it's not the end of the world if we don't have it, but I think it's an easy thing to add, and it also has the value of making the feature "complete".
Again, we're not aiming for class-style inheritance, but this augmentation approach - with the interfaces, the ref, the extensions, the implicit operator, - gives us many similar benefits, while being safe and easy to use.

[CyrusNajmabadi]

You can't do that with interfaces. It doesn't work when boxed without auto-lifting the interfaces.

I'm not sure what you mean here.

with the interfaces, the ref, the extensions, the implicit operator, - gives us many similar benefits, while being safe and easy to use.

I guess i'm asking to speak with less vagueries :) What in particular do you get? Can you whip up an example?

[TahirAhmadov]

For ref, I see a typical use case like this:

void MultiplyDependingOnCondition(ref LargeStruct<double> value)
{
  if(condition)
  {
    value.Num1 *= coefficient;
    value.Num2 *= coefficient;
    value.Num3 *= coefficient;
    value.Num4 *= coefficient;
  }
}

[TahirAhmadov]

Please look through the OP, I think I covered everything in it.

[TahirAhmadov]

I added a code snippet in the middle which explains what I mean by interfaces:

var p2Equatable = (IEquatable<Point2D>)p3Boxed; // works - because we "lifted" the interfaces

[Xyncgas]

but, just inherit the struct man

[Xyncgas]

oh you can't?

[Xyncgas]

We should be able to inherit a struct, have virtuals in the struct, override them or make them invisible like we can do with classes (new, override...)

For example

public struct StructA
{
    [ExplicitLayout(0)]
    public int MyInt32_0;
    [ExplicitLayout(4)]
    public int MyInt32_1;
}
public struct StructA2:StructA
{
    public Masked(0,8) Int64 MyInt64; //now MyInt32_0 MyInt32_1 turns invisible
}

meh maybe it's a horrible idea

[CyrusNajmabadi]

have virtuals in the struct,

structs have no vtable. there's no place to put that. That's the nature of a struct, it's just the storage for its inside data. If you want inheritance/virtuals/etc., that's already solved with classes.

[Xyncgas]

But in general what if you just use explicit layout, for example if I want to augment point2D in point3D just declare x,y,z in point3D like you normally would but also declare Point2D inside the Point3D struct and have it overlap with x,y so now you can use Point2D to access only the two values

[Xyncgas]

in fact you can even augment Vector3 into your point3D and basically gives your Point3D struct SIMD capabilities

[Xyncgas]

just overlap your fields, like in c++, or just forget about all this and take a reference and cast to another pointer type and now you have access to any member functions you want since you can cast your void* to any pointer

[TahirAhmadov]

@CyrusNajmabadi I just ran across a use case for "promoted" fields (or even properties) the way that you envisioned them, which is separate from my struct augmentation idea. Specifically, imagine your typical business software with data entities; it's frequently necessary to reuse certain properties between multiple entities, but lack of multiple inheritance prevents us from doing so elegantly. I think "promotion" would be the next best thing:

interface IOrganization
{
  promoted LegalEntityDescriptor Descriptor { get; set; }
}
class Company : IOrganization
{
  public string Name { get; set; } // if this is present, then the line below generates a compile error
  public promoted LegalEntityDescriptor Descriptor { get; set; }
}
class Charity : IOrganization
{
  public promoted LegalEntityDescriptor Descriptor { get; set; }
}
class LegalEntityDescriptor // or struct
{
  public string Name { get; set; }
  public string MailingAddress { get; set; }
}

I think it makes sense to go with explicit approach here:

• at compile time, conflicts are prohibited;
• accessing the members of the promoted type through the field/property is a warning (but getting/setting said field/property is allowed);
• promoted properties on interfaces are allowed, too, and implementing class has to follow the "promoted" rule on the property.
• if promoted field/property is nullable, then this won't work; meaning, it has to be non-null, if class, or it has to be struct.

Thoughts?

[HaloFour]

The source generator would generate delegating properties:

partial class Company : IOrganization
{
  [Promoted] public LegalEntityDescriptor Descriptor { get; set; }
}

// generated
partial class Company {
    public string Name => this.Descriptor.Name;
    // etc.
}

[HaloFour]

The problem with auto-creating said pass-through properties is that in reflection scenarios

I don't see why this is a problem. Delegation is a pretty common design pattern. This is exactly what I would expect any "first class" compiler support for such a thing to do.

[TahirAhmadov]

I don't see why this is a problem. Delegation is a pretty common design pattern. This is exactly what I would expect any "first class" compiler support for such a thing to do.

I actually think it would be the opposite for native compiler support; it makes no sense to add stuff to metadata which isn't in the code. And that, in my mind, creates a problem - if I was to write such an SG, but the language would later get the feature, it would likely be incompatible in some ways.

[HaloFour]

I actually think it would be the opposite for native compiler support

I disagree. Delegation is a very common pattern and exactly how I would expect any such feature to be implemented. I would want those members to be directly discoverable, and I would want them to be able to participate in such things as interface implementation automatically. It also puts a lot less onus on any consuming language that now doesn't need to know anything about the "magic" of promoted members, they're just normal members like any other.

And that, in my mind, creates a problem - if I was to write such an SG, but the language would later get the feature, it would likely be incompatible in some ways.

I seriously doubt that delegation will ever become a language feature. It's so easily solvable by tooling and source generators that I don't see why it would bubble up to the language level.

[TahirAhmadov]

I disagree. Delegation is a very common pattern and exactly how I would expect any such feature to be implemented. I would want those members to be directly discoverable, and I would want them to be able to participate in such things as interface implementation automatically. It also puts a lot less onus on any consuming language that now doesn't need to know anything about the "magic" of promoted members, they're just normal members like any other.

What you are saying makes sense, but I was under the impression that they don't want to create stuff in IL that doesn't exist in code. Perhaps this delegation approach does not fall under that umbrella; if so, the benefits you outlined are worthwhile, indeed.
Also, please see my idea below - thoughts?

[TahirAhmadov]

On second thought, I'm actually now thinking both the "augmentation" and the "promotion" can be combined into one, sweeping improvement.

class Person : EntityBase, IEquatable<Person>, promotes LegalEntityDescriptor
{
  // ...
}
struct Point3D : IEquatable<Point3D>, promotes Point2D // for structs, this is the same as augments above
{
  // ...
}

In fact, classes can promote structs and vice versa, as needed. This solves (for most use cases) two very important and fundamental shortcomings of C# today: lack of multiple inheritance and lack of struct inheritance. It allows greater use of structs to reduce allocations, where desirable.

[HaloFour]

In short, I think a language feature is called for here, and an SG will not suffice.

IMO, this is still a solution in search of a problem. Yes, there is friction using other tools or patterns to accomplish similar goals, but those goals are not common. If there was a desire to rework structs in C# in a meaningful way as you describe I'd much rather that be considered at the runtime level instead of the compiler level anyway as even at the compiler level there will be observable warts.

[TahirAhmadov]

IMO, this is still a solution in search of a problem.

I think you yourself created a discussion at some point asking for WrapperBase<T> type of struct for physical values, etc. I think the problem is real - the OP lists three scenarios that I thought of, and there are potentially others.

Yes, there is friction using other tools or patterns to accomplish similar goals, but those goals are not common. If there was a desire to rework structs in C# in a meaningful way as you describe I'd much rather that be considered at the runtime level instead of the compiler level anyway

How could it be solved at runtime level? Short of moving in the direction of C++ where classes can be value types, effectively removing the distinction (which is not happening), I don't see what else can be done.

as even at the compiler level there will be observable warts.

I wouldn't call them warts, rather - different expectation and realities, caused by the fundamental differences between classes and structs. Also, if we say classes can be promoted, too, it's no longer just a struct improvement.

[HaloFour]

@TahirAhmadov

I think you yourself created a discussion at some point asking for WrapperBase<T> type of struct for physical values, etc. I think the problem is real - the OP lists three scenarios that I thought of, and there are potentially others.

As a type-safe wrapper of a single value, sure, but it never attempts to pretend that the wrapper is extends from that value type. I also created it before struct record was a thing, so it's pretty much obsolete now.

I wouldn't call them warts, rather - different expectation and realities, caused by the fundamental differences between classes and structs. Also, if we say classes can be promoted, too, it's no longer just a struct improvement.

Warts still the same, and still nothing that can't be solved via delegation. Your points about it not working with ref are, IMO, intentional and important. Even without this feature odds are those would be properties and not fields anyway, precluding the ability to take a ref.

IMO a lot of these kinds of proposals come from an idea that references and allocations are always bad and should be avoided at all costs, so let's put a lot of effort into trying to make structs into classes instead, not realizing that passing around these big structs would end up being more expensive than those allocations.

[TahirAhmadov]

As a type-safe wrapper of a single value, sure, but it never attempts to pretend that the wrapper is extends from that value type. I also created it before struct record was a thing, so it's pretty much obsolete now.

If you look at the OP, you can see how it's beneficial to actually have the semantics of "extending" (or "augmenting" or "promoting") as opposed to just a simple wrapper. For example, you can have structs with physical units and multiplying certain units produces a certain other unit, meaning, multiplying watt by second produces a joule, and not a calorie, etc.

Warts still the same, and still nothing that can't be solved via delegation. Your points about it not working with ref are, IMO, intentional and important. Even without this feature odds are those would be properties and not fields anyway, precluding the ability to take a ref.

That may or may not be true in all use cases. I can see how math-heavy workloads want to write simple structs with fields and don't want to bother with interfaces and properties and all that. Also, the other ref scenario - passing the entire "base" ("promoted") struct by-ref - is also impossible in a clean manner without language support.

IMO a lot of these kinds of proposals come from an idea that references and allocations are always bad and should be avoided at all costs, so let's put a lot of effort into trying to make structs into classes instead, not realizing that passing around these big structs would end up being more expensive than those allocations.

I agree that allocations are not automatically all bad, however the way I see "promotion" working (as opposed to the original "augmentation"), it's usable for both classes and structs. Also, for structs, it would be the users' job to figure out when to use structs, as opposed to classes; the language does not mandate either way - we're just making it easier by making the struct option more complete.
For classes, it would give us a decent approximation of multiple inheritance, without any of the downsides of actual multiple inheritance. I regularly (not SUPER frequently, like daily, more like once or twice a month) have to deal with repeated code due to lack of multiple inheritance (or LoMI, as I called a special attribute in my projects). Currently, the best thing I could think of is create ugly static classes with some "common" methods, together with interfaces. All of that is terrible. (The other alternative of copying and pasting code in multiple places is much worse than terrible.)

[TahirAhmadov]

@HaloFour I just found this item you opened: #1014
What can I say, great minds think alike :)
Basically, what I think C# needs is "mixins". Your idea was a special new construct called "mixin"; my thinking was, any class/struct can be "mixed in" (promoted) into any class/struct.
I thought about it a little more and realized there is another potential here:

class Control
{
  public Point Location { get; set; }
}
struct TextControlCommon
{
  public string Text { get; set; }
  public void Draw(Graphics g) 
  {
    g.DrawString(this.Location, this.Text); // oops, Location is a property of Control 
  }
}
class Button : Control, promotes TextControlCommon
{
  public override void Draw(Graphics g)
  {
    this.TextControlCommon.Draw(g); 
  }
}

How do we make Location available to TextControlCommon? One option is:

struct TextControlCommon promotedby Control, ISomeInterface { ... }
// now all members of Control and ISomeInterfaces are available
// and TextControlCommon is no longer usable directly

[TahirAhmadov]

To anybody else who is interested in this: I did end up writing a source generator to imitate this behavior, and while it has a few downsides compared to a native language solution to allow "promotion"/"augmentation"/"mixins" - I decided to name it "composition" - it does make quite a few scenarios a lot easier.

SourceGenerator.cs

Supporting types

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct, AllowMultiple = true)]
public class ComposedOfAttribute : Attribute
{
	public ComposedOfAttribute(Type type)
	{
		this.Type = type;
	}

	public Type Type { get; }
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct)]
public class CompositionPartAttribute : Attribute
{
}

public interface IComposedOf<T>
{
	T Base { get; }
}

(BTW why aren't .cs files allowed to be attached??!!...)

PS. This is the first ever analyzer/generator I wrote - any constructive criticism is very welcome.

[TahirAhmadov]

The usage is like this:

[CompositionPart]
struct Point2D : IEquatable<Point2D>
{
  public Point2D(double x, double y) { this.X = x; this.Y = y; }
  public double X, Y;
  public bool Equals(Point2D obj) { ... }
  public Point2D Add(Point2D obj) => new Point2D(this.X + obj.X, this.Y + obj.Y);
}
[ComposedOf(typeof(Point2D))]
struct Point3D : IEquatable<Point3D>
{
  public Point3D(double x, double y, double z) { this.BasePoint2D(x, y); this.Z = z; }
  public double Z;
  public bool Equals(Point3D obj) { ... }
}
var p3 = new Point3D(1, 2, 3);
Console.Write(p3.X + ", " + p3.Y + ", " + p3.Z);

[TahirAhmadov]

I've vastly improved the source generator and created a Github repo and Nugets for it:

https://github.com/TahirAhmadov/Composition
https://www.nuget.org/packages/TA.Util.CompositionTypes/1.0.1
https://www.nuget.org/packages/TA.Util.Composition/1.0.0

[Aniobodo]

@TahirAhmadov the nugget package generates a class-like-interface with properties backed up by fields. Thinking about boxing on the generated structs, is that really the behaviour you want?

[TahirAhmadov]

@Aniobodo the interface is meant for unboxing an already boxed struct; you don't need to use it if you have the struct itself. Please refer to the code samples.

[Aniobodo]

@TahirAhmadov Got it. Support for readonly struct?

[TahirAhmadov]

Contributions are welcome :)

[TahirAhmadov]

BTW you may want to try it, I don't remember if I tested it, but I think it's actually supported.