Maybe it is better to pass PrimitiveType as parameter instead of executing an if branch at each draw call?
This would allow a greater flexibility.

We could add two overloads for the Draw method:

1. public void Draw(GraphicsDevice graphicsDevice, EffectPass pass = null)
2. public void Draw(GraphicsDevice graphicsDevice, PrimitiveType primitiveType, EffectPass pass = null)

What do you think?

It would add greater flexibility, but currently I think that geometric primitives only build TriangleLists, so I'm not sure other PrimitiveTypes really make sense. Really, either would work here, it's really a preference of how safe do you want the toolkit to be.

There is a whole lot more than TriangleLists, like TriangleStrips. I also hate functions being two functions at once having a bool passed to decide at runtime what they should do. This is bad style so I would support ArtiomsCiumac's aproach. If you want to reduce code, you better have the one method without PrimitiveType-Parameter just call the other with a predefined PrimitiveType. This makes it the same viewed from caller, but removes branching at runtime. Also you remain flexible to other PrimitiveTypes.

I understand that there are other PrimitiveTypes besides the two I've used. And I agree about your point that this isn't the best programming pattern. However, none of the current geometric primitives use anything besides TriangleLists, which is why it's currently hard coded as a TriangleList. As such, the question I was ask was whether we really want to expose the more generic function, or whether we would prefer the following pattern.

public void DrawTriList(GraphicsDevice graphicsDevice, EffectPass pass = null);
public void DrawPatch3(GraphicsDevice graphicsDevice, EffectPass pass = null);
protected void Draw(GraphicsDevice graphicsDevice, PrimitiveType primitiveType, EffectPass pass = null);

Clearly these names could be better, but this pattern prevents the developer from making a bad call, and the toolkit, generally speaking, is about providing a more user friendly experience. The question is, how user friendly do we want this api?

Good point - but I'd at least prefer two methods as you suggested, to reduce branching. But this might be just my no-branching style from GPGPU-Programming.

I would still insist on my proposal, as GeometricPrimitive class can be instantiated from an arbitrary arrays of vertex data. With DrawTriList I don't agree, as the functions will be too specialized. Let's leave the default as PrimitiveType.TriangleList.

If the developer will make a wrong call - those are his problems. A hammer manufacturer is not responsible for someone hitting his finger. There is always a balance between flexibility and safety.

@dazerdude, you made a good point about extending GeometricPrimitive functionality with this pull request - therefore adding a single overload (which accepts PrimitiveType as parameter) - will add a lot of possibilities.

Sound's good. I've updated the branch to be in line with your suggestion.